From: | francis picabia <fpicabia(at)gmail(dot)com> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | Best practise for upgrade of 24GB+ database |
Date: | 2012-01-20 18:12:13 |
Message-ID: | CA+AKB6FCmzst0vtMeu7xbemXeFeBt-_5TUnMdEB0r_pgsrVheA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
In an academic setting, we have a couple of larger than typical
Postgres databases.
One for moodle is now 15GB and another for a research project is
currently 24 GB.
I notice while upgrading Postgresql in Debian from 8.3 to 8.4, the downtime
on the 24 GB research database is extensive while using pg_upgradecluster
It has now been 26 hours of downtime for the database, and about 18GB of
the 24GB is recovered into the 8.4 destination so far.
I read some of the tips on the Postgresql wiki on performance tweaks
( http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server )
and had implemented some improvements such as shared_buffers
in the 8.3 instance prior to the upgrade. I thought if I was doing this
again, I would have found the source postgresql.conf used by
the pg_upgradecluster script for 8.4, and tuned it prior to the run.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Nicholson, Brad (Toronto, ON, CA) | 2012-01-20 18:45:07 | Re: Best practise for upgrade of 24GB+ database |
Previous Message | Kevin Grittner | 2012-01-20 15:38:34 | Re: Unable to Connect to server |