Upgrading Databases

In the middle of a large upgrade process to the home server.  Kind of a mess, but things are coming back up.

When upgrading databases, use the old, running version to make a DB dump BEFORE you upgrade the software.  I’ve just had to struggle with getting an old version of Firebird to run so I could read the databases.  Then, I had to do the same thing with PostgreSQL.

Also note that databases are really sensitive to which binary wrote the data.  I’m on a 64-bit system, but my old one was 32-bit.  Guess what?  I need 32-bit versions of the database to read the old software.

Postgres was particularly finicky as it wanted both versions running at the same time.  I figured out how to extract the prior version’s RPM into a different place and coaxed it into running from there, so I could dump into the new location.  (From the directory you want to extract into, rpm2cpio whatever.rpm | cpio -i –no-absolute-filenames -d)

Firebird was also a little problematic, as gbak doesn’t restore the database owner.  Most of my security is handled in that the owner can access the DB and no one else has rights to.  When SYSDBA owns all the databases, none of my apps work because they can’t write to their own DB with their user.  I had to restore each DB as each user, which mean I had to find all their passwords, and restore them one at a time.  My backup process will capture more of this in future.  You can see the DB owner in the output of SHOW DATABASE, but there’s no official way to change it!

The worst part is that I’ve done all this before, and I had to mess it up the second time before I decided to fix it.  Drr.

Tags: , , , , , , , ,

Leave a Reply