Re: Best practise for upgrade of 24GB+ database
От | francis picabia |
---|---|
Тема | Re: Best practise for upgrade of 24GB+ database |
Дата | |
Msg-id | CA+AKB6HeK2832DNB9uDO1DqxaH7ziaq7xFm7EWFb-nZc+n49oA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Best practise for upgrade of 24GB+ database ("Nicholson, Brad (Toronto, ON, CA)" <bnicholson@hp.com>) |
Ответы |
Re: Best practise for upgrade of 24GB+ database
Re: Best practise for upgrade of 24GB+ database |
Список | 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 по дате отправления: