Database migration update (postponed PostgreSQL outage for 27th)

Print Friendly, PDF & Email

The outage for moving the current PostgreSQL 7.4 server to pg-p0 on the 27th of July has been cancelled.

The planned outage for migrating the MySQL server on sabre to my-p0 on the 27th of July will go ahead.

The outage for upgrading the PostgreSQL server on the 10th of August will go ahead, but will now also be the migration to the new servers.

After running some tests this week it has come to light that the migration route that I have chosen is not possible for PostgreSQL. Apologies to all for the confusion and if you have notified clients of an outage to them too. The reason for this is that in order for the flat database files to be transfered (as if recovered from a disk backup) the source and destination servers need to be the same CPU architecture (and endianness) as well as the same version of database software. Because the destination server is a 64bit system and the source a 32bit system this makes the move for PostgreSQL for the 27th impossible.

Therefore; the remaining choice is to perform a full dump and restore for each database using the native tools for the destination database type. This has an advantage in that this is a required step in the process to move to a newer version of the database software. This means that I will be able to merge the outage planned for the 27th with the outage for the 10th.

Additionally, due to the sizes of some of the databases held on the current PostgreSQL instance and the length of time it will take to perform a full dump/restore, I have decided to split largest database (BOS) into it’s own instance and migrate the remaining databases, to a shared instance, in groups based on the client server that connects to the database. This will allow for shorter noticeable outages for each site and a more manageable migration.

The previous request to change the database server connection strings to the new host names is still required if you have not already done so.