On Tue, Jul 7, 2009 at 4:49 PM, Tom Lane<t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers