Skip site navigation (1) Skip section navigation (2)

Re: Best practise for upgrade of 24GB+ database

From: "Nicholson, Brad (Toronto, ON, CA)" <bnicholson(at)hp(dot)com>
To: francis picabia <fpicabia(at)gmail(dot)com>, "pgsql-admin(at)postgresql(dot)org"<pgsql-admin(at)postgresql(dot)org>
Subject: Re: Best practise for upgrade of 24GB+ database
Date: 2012-01-20 18:45:07
Message-ID: EC55DC235432104F8255702A8D7344D92572B41A@G4W3294.americas.hpqcorp.net (view raw or flat)
Thread:
Lists: pgsql-admin
> -----Original Message-----
> From: pgsql-admin-owner(at)postgresql(dot)org [mailto:pgsql-admin-
> owner(at)postgresql(dot)org] On Behalf Of francis picabia
> Sent: Friday, January 20, 2012 1:12 PM
> To: pgsql-admin(at)postgresql(dot)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 seconds for 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.

Brad.

In response to

Responses

pgsql-admin by date

Next:From: Benjamin KrajmalnikDate: 2012-01-20 20:04:18
Subject: Upgrade from 9.0.3 to 9.0.6
Previous:From: francis picabiaDate: 2012-01-20 18:12:13
Subject: Best practise for upgrade of 24GB+ database

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group