On Tue, Jul 7, 2009 at 4:49 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> This design seems totally wrong to me. It's confusing the master's
> pg_xlog directory with the archive. We should *not* use pg_xlog as
> a long-term archive area; that's terrible from both a performance
> and a reliability perspective. Performance because pg_xlog has to be
> fairly high-speed storage, which conflicts with it needing to hold
> a lot of stuff; and reliability because the entire point of all this
> is to survive a master server crash, and you're probably not going to
> have its pg_xlog anymore after that.
Hm, those are all good points.
> If slaves need to be able to get at past WAL, they should be getting
> it from a separate archive server that is independent of the master DB.
But this conflicts with earlier discussions where we were concerned
about the length of the path wal has to travel between the master and
the slaves. We want slaves to be able to be turned on simply using a
simple robust configuration and to be able to respond quickly to
transactions that are committed in the master for synchronous
operation.
Having wal have to be written to the master xlog directory, be copied
to the archive, then be copied from the archive to the slave's wal
directory, and then finally be reread and replayed in the slave means
a lot of extra complicated configuration which can be set up wrong and
which might not be apparent until things fall apart. And it means a
huge latency before the wal files are finally replayed on the slave
which will make transitioning to synchronous mode -- with a whole
other different mode of operation to configure -- quite tricky and
potentialy slow.
I'm not sure how to reconcile these two sets of priorities though.
Your points above are perfectly valid as well. How do other databases
handle log shipping? Do they depend on archived logs to bring the
slaves up to speed? Is there a separate log management daemon?
--
greg
http://mit.edu/~gsstark/resume.pdf