Re: How to upgrade from 9.1 to 9.2 with replication?

On Mon, Oct 29, 2012 at 9:53 AM, Claudio Freire <klaussfreire(at)gmail(dot)com>wrote:

> On Mon, Oct 29, 2012 at 7:41 AM, Matheus de Oliveira
> <matioli(dot)matheus(at)gmail(dot)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