Re: Moving from 7.3.4 to 7.4.x? - Mailing list pgsql-general
From | Jan Wieck |
---|---|
Subject | Re: Moving from 7.3.4 to 7.4.x? |
Date | |
Msg-id | 405C4E62.4030802@Yahoo.com Whole thread Raw |
In response to | Re: Moving from 7.3.4 to 7.4.x? (Bill Moran <wmoran@potentialtech.com>) |
Responses |
Re: Moving from 7.3.4 to 7.4.x?
|
List | pgsql-general |
Bill Moran wrote: > Bjørn T Johansen wrote: >> I am running 7.3.4 and I am thinking about upgrading to 7.4, so I was >> just wondering what pitfalls, caveats,etc I should know of? > > I recently upgraded a production system from 7.3 to 7.4 on FreeBSD. > > I used pg_dump to back up all my databases, uninstalled 7.3, deleted > the data directory, installed 7.4, ran initdb, tweaked postgres.conf, > restored the data from the dump and TADA! everything was running > just fine. As a general rule of thumb, it is recommended to use the new versions pg_dump for the backup. > > Your mileage may vary, but it worked very nicely for me. The entire > process took less than an hour, but the database is pretty small. > As a precaution, I had a binary package of 7.3 ready to reinstall in > case the 7.4 didn't take, but I didn't need it. > We know for a long time that the dump+restore requirement is a big drawback for large databases. But there is light at the horizon. The current CVS tip of Slony is not only capable of replicating master to slave between 7.3.x and 7.4.x. It can also switch over in a controlled fashion so that one slave becomes master and the master turns into a fully synchronized slave at the same time. The databases are protected against updates during the handover, so the application will experience a little time where none of the databases will accept write transactions. Read transactions succeed all the time on both databases without interruption. In case the application experiences problems with the new database version, the old version got turned into a slave, so all succssfull transactions done on the new version are replicated and switching back only becomes a problem if the failures lead to logical corruption on the new database, not caught by referential integrity. Against that case, one could guard with a second slave running the old version and that gets disconnected before the switch and would serve then as a ready restored backup. A little problem left and is to get rid of the replication system after the successfull conversion. But this will be implemented within the next week. Also the configuration tools and documentation are literally not existent. So getting this all to work requires more running "setup". I plan to make a pre-release of Slony-I within the next 3-4 weeks. This will not include failover and a few other features. But it will be fully capable of doing 2 machine DB version upgrades via replication as described above. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
pgsql-general by date: