On Mon, Oct 29, 2012 at 9:53 AM, Claudio Freire <klaussfre...@gmail.com>wrote:
> On Mon, Oct 29, 2012 at 7:41 AM, Matheus de Oliveira > <matioli.math...@gmail.com> wrote: > > >> > >> 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? > 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). Regards, -- Matheus de Oliveira Analista de Banco de Dados PostgreSQL Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
