This site works best in a real browser - Server Migration

Database migration

nospam@example.com (Graham Cox) — Thu, 28 Sep 2006 09:49:35 +0100

Migration of actual database across is something that was not working at all last time I tried it, and that I have managed to make work perfectly this time around.

In order to migrate a database from an older version of Postgres to a newer version, you need to do a dump and restore of the data. Unfortunatly, the pg_dump tool on Postgres 7.3 doesn't dump Schemas in a form that Postgres 8.1 will restore, and so if you do this you end up with all of your tables and functions in the Public schema instead of the schemas you put them in.

However, there is a simple way around this, and one that works very easy and even removes a step from the migration.

Before, I was attempting to do the migration as follows:
This assumes that you have already created the database and users prior to importing the data.



oldserver$ pg_dump -f database.sql database



newserver$ scp oldserver:database.sql .

newserver$ psql -d database -f database.sql

The new method that I have been using, that seems so far to work perfectly, is as follows:



newserver$ pg_dump -f database.sql -h oldserver -U graham database

newserver$ psql -d database -f database.sql

In order to do this, there are a few things that need to be done first. Namely,
# Allow newserver to access oldserver. I did this by just putting a whitelist entry in the firewall on oldserver.
# Allow newserver to access the Postgres databases on oldserver. This is done by editing pg_hba.conf
# Allow the user to log in remotely. This is done by the settings in pg_hba.conf, and by making sure the user has a password you know.

The trick here is that the pg_dump that comes with Postgres 8.1 knows how to dump data from an older version of Postgres, but it dumps it in a format that the newer version is able to import properly.

Subversion Migration

nospam@example.com (Graham Cox) — Thu, 28 Sep 2006 09:34:16 +0100

Subversion Migration has been relatively painless. The only difficult part turned out to be the bit that I always have trouble with - installing the Python bindings so that ViewVC and other tools will work with it.

When installing Subversion, you go through the standard set of steps - ./configure, make, make check, sudo make install. What you also have to do in order to get the subversion python bindings installed I keep having to go and dig up on the internet.

It is not downloading the pysvn package and installing that. This is either an alternative or an older version of what is actually included with Subversion and does not do the complete job that ViewVC needs from it.

Instead, what you have to do is the following:

From the Subversion source directory, execute



$ make swig-py

$ sudo make install-swig-py

As it happens, this is mentioned in the INSTALL for Subversion. However, it's a small section right at the bottom of the file that refers you to read a different file that gives you the instructions.

Software installation

nospam@example.com (Graham Cox) — Wed, 27 Sep 2006 13:46:48 +0100

The complete list of "core" software that I have installed on the new server is as below.
Core software is the list of Systems software that I have installed myself - it doesn't include things like SSH which, whilst is Systems software, was pre-installed on the system. It instead is the list of software for what the server is actually going to be doing.

Apache - 2.2.3 - Webserver
Subversion - 1.3.1 - Version control
PostgreSQL - 8.1.4 - Database
PHP - 5.1.6 - Web software
Asterisk - 1.2 - VoIP Server.

Out of all of these, the only one that I had to install an older version of was Asterisk. This was because the dialplan and config that I already have doesn't appear to work on the latest trunk version, and it was too much hassle to make it all work now. That's a project for the future.

Server Migration

nospam@example.com (Graham Cox) — Wed, 27 Sep 2006 13:41:39 +0100

My old server wasn't good enough for everything that I was doing on it. Given the huge list of things I was doing on it, this wasn't surprising. Where it wasn't good enough was when I was trying to get it to run PostgreSQL 8.1 instead of 7.3 that it came with.

As such, I have migrated across to a bigger server - the Servelocity Unlimited+ FC5 server - and started installing everything on there.

This is actually the second time I'm attempting this. The first time was a couple of weeks ago, and the server that I got had issues with it that meant I wasn't going to use it. I have now got a good server and got all the software installed and running.