On Mon, Jan 23, 2012 at 8:02 PM, Alan Hodgson <ahodgson@xxxxxxxxx> wrote: > On Monday, January 23, 2012 07:54:16 PM Andrew Hannon wrote: >> It is worth noting that, the slave (seemingly) catches up eventually, >> recovering later log files with streaming replication current. Can I trust >> this state? >> > > Should be able to. The master will also actually retry the logs and eventually > ship them all too, in my experience. > Right, as long as the failure case is temporary, the master should retry, and things should work themselves out. It's good to have some level of monitoring in place for such operations to make sure replay doesn't get stalled. That said, have you tested this backup? I'm a little concerned you'll have ended up with something unusable because you aren't starting xlog files that are going on during the snapshot time. It's possible that you won't need them in most cases (we have a script called "zbackup"[1] which does similar motions using zfs, though on zfs the snapshot really is instantaneous, in I can't remember a time when we got stuck by that, but that might just be faulty memory. A better approach would probably be to take the omnipitr code [2], which already had provisions for slaves from backups and catching the appropriate wal files, and rewrite the rsync bits to use snapshots instead, which would give you some assurances against possibly missing files. [1] this script is old and crufty, but provides a good example: http://labs.omniti.com/labs/pgtreats/browser/trunk/tools/zbackup.sh [2] https://github.com/omniti-labs/omnipitr Robert Treat conjecture: xzilla.net consulting: omniti.com -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
