Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TPEpP-0005la-Gs for pgsql-performance@postgresql.org; Fri, 19 Oct 2012 15:49:39 +0000 Received: from wsip-70-169-168-7.pn.at.cox.net ([70.169.168.7] helo=FS.denninger.net) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TPEpK-00080W-PQ for pgsql-performance@postgresql.org; Fri, 19 Oct 2012 15:49:39 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.4/8.13.1) with ESMTP id q9JFnXZF077960 for ; Fri, 19 Oct 2012 10:49:33 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Fri Oct 19 10:49:33 2012 Message-ID: <50817685.3060207@denninger.net> Date: Fri, 19 Oct 2012 10:49:25 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Claudio Freire CC: delongboy , pgsql-performance@postgresql.org Subject: Re: How to upgrade from 9.1 to 9.2 with replication? References: <1350598882643-5728941.post@n5.nabble.com> <50816749.6010804@denninger.net> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: multipart/alternative; boundary="------------060105050900090702070708" X-Antivirus: avast! (VPS 121019-0, 10/19/2012), Outbound message X-Antivirus-Status: Clean X-Pg-Spam-Score: -0.9 (/) X-Archive-Number: 201210/274 X-Sequence-Number: 48233 This is a multi-part message in MIME format. --------------060105050900090702070708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by FS.denninger.net id q9JFnXZF077960 On 10/19/2012 10:02 AM, Claudio Freire wrote: > On Fri, Oct 19, 2012 at 11:44 AM, Karl Denninger w= rote: >> On 10/18/2012 5:21 PM, delongboy wrote: >> >> I have replication set up on servers with 9.1 and want to upgrade to 9= .2 >> I was hoping I could just bring them both down, upgrade them both and = bring >> them both up and continue replication, but that doesn't seem to work, = the >> replication server won't come up. >> Is there anyway to do this upgrade with out taking a new base backup a= nd >> rebuilding the replication drive? >> >> Not that I know of. >> >> I tried this as well when the development branches were out in a "sand= box" >> and it failed as it did for you. >> >> For 9.1 -> 9.2 what I did was bring down the cluster, upgrade the mast= er, >> then initdb the slave and run the script that brings over a new baseba= ckup >> with the WAL archives ("-x" switch), and when complete just started th= e >> slave back up in slave mode. >> >> 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 e= nough >> to make it reasonable; for the actual backup units at a remove it take= s a >> while as the copy has to go across a WAN link. I cheat on that by usi= ng a >> SSH tunnel with compression turned on (which, incidentally, it would b= e >> really nice if Postgres supported internally, and it could quite easil= y -- >> 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 > rsync master->slave (differential update, much faster than basebackup) > Bring slave up That's an interesting idea that might work; are replicated servers in a consistent state guaranteed to have byte-identical filespaces? (other than the config file(s), of course) I have not checked that assumption. Surprises in that regard could manifest in very unfortunate results that only become apparent a significant distance down the road. --=20 -- Karl Denninger /The Market Ticker =AE/ Cuda Systems LLC --------------060105050900090702070708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/19/2012 10:02 AM, Claudio Freire wrote:
On Fri, Oct 19, 2012 at 11:44 AM, Karl Denninger <karl@denninger.net> wrote:

On 10/18/2012 5:21 PM, delongboy wrote:

I have replication set up on servers with 9.1 and want to upgrade to 9.2
I was hoping I could just bring them both down, upgrade them both and bring
them both up and continue replication, but that doesn't seem to work, the
replication server won't come up.
Is there anyway to do this upgrade with out taking a new base backup and
rebuilding the replication drive?

Not that I know of.

I tried this as well when the development branches were out in a "sandbox"
and it failed as it did for you.

For 9.1 -> 9.2 what I did was bring down the cluster, upgrade the master,
then initdb the slave and run the script that brings over a new basebackup
with the WAL archives ("-x" switch), and when complete just started the
slave back up in slave mode.

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
rsync master->slave (differential update, much faster than basebackup)
Bring slave up
That's an interesting idea that might work; are replicated servers in a consistent state guaranteed to have byte-identical filespaces? (other than the config file(s), of course)  I have not checked that assumption.

Surprises in that regard could manifest in very unfortunate results that only become apparent a significant distance down the road.

--
-- Karl Denninger
The Market Ticker ®
Cuda Systems LLC
--------------060105050900090702070708--