MIME-Version: 1.0
In-Reply-To: <4241f359-ec01-dc73-f742-20fdbc81755a@BlueTreble.com>
References: 
 <CAEaSS0atiPVYLhMSwtzcZB5efeTxYjYDR1s3OZSshpkAY1VsAg@mail.gmail.com>
 <20160304225811.GE865@telsasoft.com> <56E2F672.7080305@BlueTreble.com>
 <CAEaSS0bi0oAk2u615P-WmtLj3XfvAeBBLgO05nxyK5tD7Pui5Q@mail.gmail.com>
 <57014F54.3050204@BlueTreble.com>
 <CAEaSS0Z-0eNY2Qhc8D5ywdRFxadHEhAZkEuYOeZCKxfOt142Mg@mail.gmail.com>
 <4241f359-ec01-dc73-f742-20fdbc81755a@BlueTreble.com>
From: Tory M Blue <tmblue@gmail.com>
Date: Tue, 14 Jun 2016 14:08:15 -0700
Message-ID: 
 <CAEaSS0Z=p8e5DVw+K3N4rBc5WcoaOVBULKNjtUMmcejb_r15ZA@mail.gmail.com>
Subject: Re: Clarification on using pg_upgrade
To: Jim Nasby <Jim.Nasby@bluetreble.com>
Cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On Tue, Jun 14, 2016 at 2:03 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 4/19/16 11:01 PM, Tory M Blue wrote:
>>>>
>>>> >> Slon is also starting to not be viable as it takes some indexes over
>>>> >> 7
>>>> >> hours to complete. So this upgrade path seemed to really be nice.
>>>
>>> >
>>> >
>>> > If you're standing up a new replica from scratch on the latest version,
>>> > I'm
>>> > not really sure why that matters?
>>
>> Not sure why the 7-13 hours causes an issue? Because if I'm upgrading
>> via slon process, I have to add and drop a node. If I'm dropping my
>> secondary (slave) I have to move reporting to the master, so now the
>> master is handing normal inserts and reports. Next item, I'm  without
>> a replica for 13+ hours, that's not good either.
>
>
> Don't drop and add a node, just do a master switchover. AFAIK that's nearly
> instant as long as things are in sync.
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
> 855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

Right, that's what we do, but then to upgrade, we have to drop/add the
node, because it's being upgraded.  If I'm updating the underlying OS,
I have to kill it all. If I'm doing a postgres upgrade, using an old
version of slon, without using pg_upgrade, I have to drop the db,
recreate it, which requires a drop/add.

I'm trying to figure out how to best do it using pg_upgrade  instead
of the entire drop/add for postgres upgrades (which are needed if you
are using slon as an upgrade engine for your db).

Tory


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance