On Fri, 2008-09-12 at 00:03 +0900, Fujii Masao wrote:
> In my procedure, old WAL files are copyed by admin using scp, rsync
> or other external tool. So, I don't think that my procedure makes a
> problem more difficult. Since there are many setup cases, we should
> not leave all procedures to postgres, I think.
So the procedure is
1. Startup WALReceiver to begin receiving WAL
2. Do some manual stuff
3. Initiate recovery
So either
* WALReceiver is not started by postmaster.
I don't think its acceptable that WALReceiver is not under the
postmaster. You haven't reduced the number of failure modes by doing
that, you've just swept the problem under the carpet and pretended its
not Postgres' problem.
* Postgres startup requires some form of manual process, as an
**intermediate** stage.
I don't think either of those is acceptable. It must just work.
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.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support