On Mon, Oct 29, 2012 at 7:41 AM, Matheus de Oliveira <matioli.matheus@xxxxxxxxx> wrote: > I also think that's a good option for most case, but not because it is > faster, in fact if you count the whole process, it is slower. But the master > will be on backup state (between pg_start_backup and pg_stop_backup) for a > small period of time which make things go faster on the master (nothing > different on slave though). Exactly the point. >> >> Just for the record, we do this quite frequently in our pre-production >> servers, since the network there is a lot slower and replication falls >> irreparably out of sync quite often. And nobody notices when we >> re-sync the slave. (ie: downtime at the master is nonexistent). >> > > 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? -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
