On Fri, Oct 19, 2012 at 12:02:49PM -0300, Claudio Freire wrote:
> > This unfortunately does require a new data copy to be pulled across to the
> > slave. For the local copies this isn't so bad as wire speed is fast enough
> > to make it reasonable; for the actual backup units at a remove it takes a
> > while as the copy has to go across a WAN link. I cheat on that by using a
> > SSH tunnel with compression turned on (which, incidentally, it would be
> > really nice if Postgres supported internally, and it could quite easily --
> > I've considered working up a patch set for this and submitting it.)
> >
> > For really BIG databases (as opposed to moderately-big) this could be a
> > much-more material problem than it is for me.
>
> Did you try?
>
> Bring both down.
> pg_upgrade master
> Bring master up
> pg_upgrade slave
Is there any reason to upgrade the slave when you are going to do rsync
anyway? Of course you need to install the new binaries and libs, but it
seems running pg_upgrade on the standby is unnecessary.
> rsync master->slave (differential update, much faster than basebackup)
> Bring slave up
Good ideas. I have applied the attached doc patch to pg_upgrade head
and 9.2 docs to suggest using rsync as part of base backup.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
