On Mon, Oct 29, 2012 at 9:09 AM, Matheus de Oliveira <matioli.matheus@xxxxxxxxx> wrote: >> > If you have incremental backup, a restore_command on recovery.conf seems >> > better than running rsync again when the slave get out of sync. Doesn't >> > it? >> >> What do you mean? >> >> Usually, when it falls out of sync like that, it's because the >> database is undergoing structural changes, and the link between master >> and slave (both streaming and WAL shipping) isn't strong enough to >> handle the massive rewrites. A backup is of no use there either. We >> could make the rsync part of a recovery command, but we don't want to >> be left out of the loop so we prefer to do it manually. As noted, it >> always happens when someone's doing structural changes so it's not >> entirely unexpected. >> >> Or am I missing some point? > > > What I meant is that *if* you save you log segments somewhere (with > archive_command), you can always use the restore_command on the slave side > to catch-up with the master, even if streaming replication failed and you > got out of sync. Of course if you structural changes is *really big*, > perhaps recovering from WAL archives could even be slower than rsync (I > really think it's hard to happen though). I imagine it's automatic. We have WAL shipping in place, but even that gets out of sync (more segments generated than our quota on the archive allows - we can't really keep more since we lack the space on the server we put them). -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
