Skip site navigation (1) Skip section navigation (2)

Re: Streaming Replication and archiving

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming Replication and archiving
Date: 2010-01-19 22:35:40
Message-ID: m2hbqh7mf7.fsf@hi-media.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

Regards,
-- 
dim

PS: maybe the states and transitions and what data flows from where to
where in each of those would be good at least in the documentation, if
not explicit in the code?

In response to

Responses

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-01-19 22:37:36
Subject: Re: MySQL-ism help patch for psql
Previous:From: Joshua D. DrakeDate: 2010-01-19 22:34:54
Subject: Re: Mammoth in Core?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group