Re: archive_command and streaming replication

From: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Scott Briggs *EXTERN*" <scott(dot)br(at)gmail(dot)com>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: archive_command and streaming replication
Date: 2012-05-16 10:28:20
Message-ID: D960CB61B694CF459DCFB4B0128514C207E6A4F3@exadv11.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Christian J. Dietrich 2012-05-16 11:27:18 missing pg_clog files after pg_upgrade
Previous Message Raymond O'Donnell 2012-05-16 09:08:03 Re: Naming conventions