Thanks Laurenz for the response.
So if you do need to use wal files to catch up a slave, what would
that process be? If you caught up with wal files, how would streaming
replication know what positon to start at? And how would you tell
streaming replication the new position after catching up with wal
files?
Cheers,
Scott
On Wed, May 16, 2012 at 6:28 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
> Scott Briggs wrote:
>> Hi, can someone please explain the purpose of archive_command on both
>> the master and slave when it comes to streaming replication? From
>> what I understand so far, what really matters is how many pg_xlog
>> files are kept when it comes to reestablishing replication when it
>> breaks for some reason.
>>
>> Let's say I shutdown one slave to create a second slave by copying all
>> the files to that new slave. If I want to guarantee that the original
>> slave is able to reestablish replication, I just need to make sure
>> that the master keeps enough pg_xlog files (defined by the setting
>> "checkpoint_segments") around in order for that to happen (especially
>> in the event that the database is large).
>
> First, there are other uses of archive_command than streaming
> replication - you may want to recover the database in case of
> problems.
>
> Also, it is a good idea to have the setting the same (or
> comparable) on master and slave so that promotion of the slave
> to master is easier.
>
> But in principle you are right; if you keep the WAL files
> in pg_xlog long enough, you won't need the archives for streaming
> replication. Note, however, that the parameter you must set
> to retain them long enough is wal_keep_segments and not
> checkpoint_segments.
>
> I think that the main reason to have shared WAL archives in
> streaming replication is that it still may happen that the
> slave lags too long, like a server crash or a network problem.
> That could then mean that you have to rebuild the slave if
> you have no WAL archives that enable the slave to catch up.
>
> Yours,
> Laurenz Albe
