On Wed, 2008-09-10 at 17:57 +0900, Fujii Masao wrote:
> My sequence covers several cases :
>
> * There is no missing WAL file.
> * There is a lot of missing WAL file.
This is the likely case for any medium+ sized database.
> * There are missing history files. Failover always generates the gap
> of
> history file because TLI is incremented when archive recovery is
> completed.
Yes, but failover doesn't happen while we are configuring replication,
it can only happen after we have configured replication. It would be
theoretically possible to take a copy from one server and then try to
synchronise with a 3rd copy of the same server, but that seems perverse
and bug prone. So I advise that we only allow replication when the
timeline of the standby matches the timeline of the master, having it as
an explicit check.
> In your design, does not initial setup block the master?
> Does your design cover above-mentioned case?
The way I described it does not block the master. It does defer the
point at which we can start using synchronous replication, so perhaps
that is your objection. I think it is acceptable: good food takes time
to cook.
I have thought about the approach you've outlined, though it seems to me
now like a performance optimisation rather than something we must have.
IMHO it will be confusing to be transferring both old and new data at
the same time from master to slave. We will have two different processes
sending and two different processes receiving. You'll need to work
through about four times as many failure modes, all of which will need
testing. Diagnosing problems in it via the log hurts my head just
thinking about it. ISTM that will severely impact the initial robustness
of the software for this feature. Perhaps in time it is the right way.
Anyway, feels like we're getting close to some good designs. There isn't
much difference between what we're discussing here.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
