Simon Riggs wrote:
> Why not:
> 1. Same procedure as Warm Standby now
> a) WAL archiving to standby starts
> b) base backup
>
> 2. Startup standby, with additional option to stream WAL. WALReceiver
> starts, connects to Primary. Primary issues log switch. Archiver turns
> itself off after sending that last file. WALSender starts streaming
> current WAL immediately after log switch.
>
> 3. Startup process on standby begins reading WAL from point mentioned by
> backup_label. When it gets to last logfile shipped by primary's
> archiver, it switches to reading WAL files written by WALReceiver.
>
> So all automatic. Uses existing code. Synchronous replication starts
> immediately. Also has the advantage that we do not get WAL bloat on
> primary. Configuration is almost identical to current Warm Standby, so
> little change for existing Postgres sysadmins.
I totally agree. Requiring the master to be down for a significant time
to add a slave isn't going to keep people happy very long. We have the
technology now to allow warm standby slaves by using PITR, and it seems
a similar system can be used to setup slaves, and for cases when the
slave drops off and has to rejoin. The slave can use the existing
'restore_command' command to pull all WAL files it needs, and then the
slave needs to connect to the master and say it is ready for WAL files.
The master is going to need to send perhaps everything from the start of
the existing WAL file so the slave is sure to get all changes during the
switch from 'restore_command' to network-passed WAL info.
I can imagine the slave going in and out of network connectivity as long
as the required PITR files are still available.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +