Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <karl@denninger.net>) id 1TPDoR-0005IB-Oy
	for pgsql-performance@postgresql.org; Fri, 19 Oct 2012 14:44:35 +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 <karl@denninger.net>) id 1TPDoO-0006z0-HK
	for pgsql-performance@postgresql.org; Fri, 19 Oct 2012 14:44:35 +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 q9JEiUxn074329
	for <pgsql-performance@postgresql.org>;
	Fri, 19 Oct 2012 09:44:30 -0500 (CDT)
	(envelope-from karl@denninger.net)
Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL);
	Fri Oct 19 09:44:30 2012
Message-ID: <50816749.6010804@denninger.net>
Date: Fri, 19 Oct 2012 09:44:25 -0500
From: Karl Denninger <karl@denninger.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: delongboy <sdelong@saucontech.com>
CC: pgsql-performance@postgresql.org
Subject: Re: How to upgrade from 9.1 to 9.2 with replication?
References: <1350598882643-5728941.post@n5.nabble.com>
In-Reply-To: <1350598882643-5728941.post@n5.nabble.com>
X-Enigmail-Version: 1.4.5
Content-Type: multipart/alternative;
	boundary="------------020701020702080206050700"
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/266
X-Sequence-Number: 48225

This is a multi-part message in MIME format.
--------------020701020702080206050700
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
	q9JEiUxn074329


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 b=
ring
> them both up and continue replication, but that doesn't seem to work, t=
he
> replication server won't come up.
> Is there anyway to do this upgrade with out taking a new base backup an=
d
> 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.

--
-- Karl Denninger
/The Market Ticker =AE/ <http://market-ticker.org>
Cuda Systems LLC

--------------020701020702080206050700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 10/18/2012 5:21 PM, delongboy wrote:<br>
    </div>
    <blockquote cite="mid:1350598882643-5728941.post@n5.nabble.com"
      type="cite">
      <pre wrap="">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?
</pre>
    </blockquote>
    Not that I know of.<br>
    <br>
    I tried this as well when the development branches were out in a
    "sandbox" and it failed as it did for you.<br>
    <br>
    For 9.1 -&gt; 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.<br>
    <br>
    This unfortunately does require a new data copy to be pulled across
    to the slave.&nbsp; 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.&nbsp;
    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.)<br>
    <br>
    For really BIG databases (as opposed to moderately-big) this could
    be a much-more material problem than it is for me.<br>
    <br>
    <blockquote cite="mid:1350598882643-5728941.post@n5.nabble.com"
      type="cite">
    </blockquote>
    <div class="moz-signature">--<br>
      -- Karl Denninger<br>
      <a href="http://market-ticker.org"><i>The Market Ticker &reg;</i></a><br>
      Cuda Systems LLC</div>
  </body>
</html>

--------------020701020702080206050700--