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:

Previous
From: Tino Wildenhain
Date:
Subject: Re: Post to hacker list
Next
From: Francisco Reyes
Date:
Subject: Re: Post to hacker list