On Wed, 2008-09-10 at 15:15 +0900, Fujii Masao wrote:
> On Wed, Sep 10, 2008 at 12:26 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
> > If a slave falls behind, how does it catch up? I guess you're saying that it
> > can't fall behind, because the master will block before that happens. Also
> > in asynchronous replication? And what about when the slave is first set up,
> > and needs to catch up with the master?
>
> The mechanism for the slave to catch up with the master should be
> provided on the outside of postgres.
So you mean that we still need to do initial setup (copy backup files
and ship and replay WAL segments generated during copy) by external
WAL-shipping tools, like walmgr.py, and then at some point switch over
to internal WAL-shipping, when we are sure that we are within same WAL
file on both master and slave ?
> I think that postgres should provide
> only WAL streaming, i.e. the master always sends *current* WAL data
> to the slave.
>
> Of course, the master has to send also the current WAL *file* in the
> initial sending just after the slave starts and connects with it.
I think that it needs to send all WAL files which slave does not yet
have, as else the slave will have gaps. On busy system you will generate
several new WAL files in the time it takes to make master copy, transfer
it to slave and apply WAL files generated during initial setup.
> Because, at the time, current WAL position might be in the middle of
> WAL file. Even if the master sends only current WAL data, the slave
> which don't have the corresponding WAL file can not handle it.
I agree, that making initial copy may be outside the scope of
Synchronous Log Shipping Replication, but slave catching up by
requesting all missing WAL files and applying these up to a point when
it can switch to Sync mode should be in. Else we gain very little from
this patch.
---------------
Hannu