Re: Streaming Replication and archiving
От | Mark Kirkwood |
---|---|
Тема | Re: Streaming Replication and archiving |
Дата | |
Msg-id | 4B564B55.8050600@catalyst.net.nz обсуждение исходный текст |
Ответ на | Re: Streaming Replication and archiving (Dimitri Fontaine <dfontaine@hi-media.com>) |
Ответы |
Re: Streaming Replication and archiving
|
Список | pgsql-hackers |
Dimitri Fontaine wrote: > Mark Kirkwood <mark.kirkwood@catalyst.net.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
В списке pgsql-hackers по дате отправления: