Re: Streaming Replication and archiving

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming Replication and archiving
Date: 2010-01-20 00:16:21
Message-ID: 4B564B55.8050600@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine wrote:
> Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> writes:
>
>> I've been using the wiki page
>> (http://wiki.postgresql.org/wiki/Streaming_Replication) as a guide, and I
>> notice that it recommends the master (and replicas) have a non-trivial
>> archive_command even after the backup step is completed. ISTM that after the
>> backup the master's archive_command can be set to '' or '/bin/true' as the
>> walsender does not make any use of the WAL archive (AFAICS anyway). Clearly
>> it might be desirable to have the archived segments around for other reasons
>> - but equally it might be desirable *not* to have to have to (e.g disk
>> space), or am I overlooking something?
>>
>
> I think it's still necessary in the case the connection between a slave
> and the master breaks. If the transient error is long enough for the
> slave requesting WALs that the master no longer has, restore_command
> will get used.
>
> IIUC from the mails here, the restore_command is run directly by the
> slave itself, so it needs to have access to master archives embedded in
> the restore_command.
>
> Take all this with a huge grain of salt, that's my understanding without
> having had the time to read the patch or play with it yet.
>
>
Thanks Dimitri, I'd missed that thread. Ok, slave will need a suitable
restore_comand in addition to primary_conninfo in recovery.conf, and
then extended communication failures (or shutting down the slave for a
while!) will not break the streaming setup (FWIW I tried this just now).

regards

Mark

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2010-01-20 00:19:21 Re: Listen / Notify - what to do when the queue is full
Previous Message Tom Lane 2010-01-20 00:13:27 Re: Patch rev 2: MySQL-ism help patch for psql