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

Re: Best practise for upgrade of 24GB+ database

From: francis picabia <fpicabia(at)gmail(dot)com>
To: "Nicholson, Brad (Toronto, ON, CA)" <bnicholson(at)hp(dot)com>
Cc: "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 20:38:34
Message-ID: CA+AKB6HeK2832DNB9uDO1DqxaH7ziaq7xFm7EWFb-nZc+n49oA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
On Fri, Jan 20, 2012 at 2:45 PM, Nicholson, Brad (Toronto, ON, CA)
<bnicholson(at)hp(dot)com> wrote:
>
>> -----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.

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

In response to

Responses

pgsql-admin by date

Next:From: Kevin GrittnerDate: 2012-01-20 21:34:46
Subject: Re: Meta data information on tables
Previous:From: jkellsDate: 2012-01-20 20:22:20
Subject: Meta data information on tables

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