Re: Best practise for upgrade of 24GB+ database - Mailing list pgsql-admin

From francis picabia
Subject Re: Best practise for upgrade of 24GB+ database
Date
Msg-id CA+AKB6HeK2832DNB9uDO1DqxaH7ziaq7xFm7EWFb-nZc+n49oA@mail.gmail.com
Whole thread Raw
In response to Re: Best practise for upgrade of 24GB+ database  ("Nicholson, Brad (Toronto, ON, CA)" <bnicholson@hp.com>)
Responses Re: Best practise for upgrade of 24GB+ database  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Best practise for upgrade of 24GB+ database  ("Nicholson, Brad (Toronto, ON, CA)" <bnicholson@hp.com>)
List pgsql-admin
On Fri, Jan 20, 2012 at 2:45 PM, Nicholson, Brad (Toronto, ON, CA)
<bnicholson@hp.com> wrote:
>
>> -----Original Message-----
>> From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-
>> owner@postgresql.org] On Behalf Of francis picabia
>> Sent: Friday, January 20, 2012 1:12 PM
>> To: pgsql-admin@postgresql.org
>> Subject: [ADMIN] Best practise for upgrade of 24GB+ database
>>
>> How do others manage larger database upgrades while minimizing
>> downtime?  Do you avoid pg_upgradecluster and simply do a pg_restore
>> from a dump made prior to the upgrade?  Do you run a replication
>> and then resync it after the upgrade is complete?  Googling for info
>> on this I've only found remarks about it taking longer than you'd
>> expect.
>
> In the past I've used Slony to upgrade much larger database clusters than yours with minimal down time (I'm talking
secondsfor the actual master switch).  You set up a new replica on the new version and then move the master from old to
new. No need to explicitly resync afterwards. 

That's great information.  9.0 is introducing streaming replication,
so that is another option I'll look into.

pgsql-admin by date:

Previous
From: "Benjamin Krajmalnik"
Date:
Subject: Upgrade from 9.0.3 to 9.0.6
Next
From: jkells
Date:
Subject: Meta data information on tables