After wanting to test WordPress 3.0 on a 1and1 hosting account, I ran into the following issue… the particular setup I was dealing with had only one database available, and it wasn’t MySQL 5, but instead MySQL 4… furthermore, it was a version lower than 4.1.2, which more recent versions of WordPress require as a minimum.

So after doing a bit of research on what others had done, I went about fixing the problem. Interestingly enough, 1and1 could have made some money in this situation if they would allow customers to simply purchase another database to add to their packages, but no, they want an entire upgrade to be purchased.

The first step was to backup the website and database. I ssh’ed into the web host:

username@localhostname:~$ ssh $username@example.com

Then I backed up the database. The command below will dump all of the databases on the host (in this case, only one MySQL 4.x database) into a dated bzip file, in the home directory.

username@remotehostname:~$ mysqldump -C -A -u $databaseUsername -h $databaseHostName -p$databasePassword | bzip2 -cq9 > ~/`date +%F-%I-%M-%p`-db-backup.sql.bz2

Now to backup the site itself (not only in case disaster struck, but this would get a local copy of the sql dump I just made as well). On a local OS X workstation (or Ubuntu, if that suits your tastes) I ran something similar to the following:

username@localhostname:~$ mkdir ~/website_backups
username@localhostname:~$ rsync -avz --exclude="logs" $username@example.com: ~/website_backups/

From there, I was able to log into the 1and1 control panel and delete the existing database. This allowed me to setup a new one, and in particular, choose MySQL 4 or 5 as the type.

Back to the 1and1 hosting account:

username@localhostname:~$ ssh $username@example.com

I uncompressed the sql dump:

username@remotehostname:~$ bunzip2 2010-01-14-01-59-PM-db-backup.sql.bz2

and was greeted with the raw sql in the file, “2010-01-14-01-59-PM-db-backup.sql”. From here it was only a hop skip and a jump away to restoration. It was necessary to edit the sql file in order to have it restore properly to the newly created database that was just created:

username@remotehostname:~$ nano -w 2010-01-14-01-59-PM-db-backup.sql

And I changed the $oldDatabaseName to $newDatabaseName.

--
-- Current Database: `$oldDatabaseName`
--

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `$oldDatabaseName`;

USE `$oldDatabaseName`;

ctrl+o, enter, and ctrl+x, to save the file and exit nano. The sql dump was now ready to restore to the new database.

username@remotehostname:~$ mysql -u $databaseUsername -h $databaseHostName -p$databasePassword $databaseName < 2010-01-14-01-59-PM-db-backup.sql

The only other things to do were to update any existing applications that needed the new database name, username, hostname, and password.

As a note, if you are updating a WordPress install to point to a new database, this info can be changed in the file, wp-config.php.