| 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: | Whole Thread | Raw Message | 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 |