On Mon, Oct 29, 2012 at 9:53 AM, Claudio Freire <klaussfreire@xxxxxxxxx> wrote:
What do you mean?
>>
>> 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?
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
