I had a couple of interesting days last weekend fighting with MySQL, WordPress and DNS. This past weekend, I decided to upgrade this blog, which has about 800 posts and 4000+ comments to WordPress 2.0. As part of this move, I was also going to move hosts from pair.com to Kattare, a kick-ass hosting company (more about Kattare later).

Now I have 7 other blogs and sites that use WordPress and I’ve upgraded them all successfully to WordPress 2.0 without any problems. But my primary blog is the biggest and so I saved it for last. Since I had two different hosts and servers, I was able to setup everything without doing an upgrade in place. So I start by backing up the database from my current host using the WordPress backup plugin. I then use the MySQL Query Browser to upload the script and create the database and load up the content. The database creation worked but I ended up with some SQL errors in the process as it was loading data in the tables. But the MySQL query browser didn’t articulate the errors and so I assumed that the WordPress Database Backup plugin might have some issues and created the extract with some errors. So I use the MySQL Administrator to backup the original database and then restore it over on the new host and I got the same errors. So I look at the backup SQL script and I notice that some of the posts that are missing from the database have a special character in them that looks like this image. I’m guessing this is a weird issue with the textile plugin I use to create most post entries but I am not sure. So I start manually updating the database and fixing the missing posts. After I got all of the special characters out of the SQL dump file, I recreate the database and fire up the WordPress upgrade script. As promised, the upgrade scripts spins for a while and then returns successfully with the upgraded blog now running under WordPress 2.0.

I take a cursory look and everything appears to be ok (mistake #1) and so I go over to my host registrar and switch the DNS over to my new hosting company. I did this without updating the TTL on the DNS record (mistake #2) and the default TTL was 24 hours. The DNS changes propagate right away and I see my upgraded blog in minutes and so I start doing a little QA to make sure everything is working as it should. I soon discover that something is awry as some of my pages don’t work. I see them in the database and the WordPress admin with the correct post slug, but I get a 404 when I try to view it. I verify that .htaccess is setup correctly and the page is setup correctly but still cannot view. Some of the comments are missing as well and so my hand-edit of the WordPress database didn’t fix everything or maybe fixed one issue and created 2 new ones. Since I have a working installation of WordPress 1.5 on my old host, I go back to update the DNS to switch back to pair.com. My second mistake of not updating the DNS TTL record bites me here as it’s now going to take anywhere from 24-48 hours to go back to the old host. Good lesson learned here for when I try this again.

The chart is courtesy of the Stephen Pierzchala’s GrabPERF blog performance monitoring system.

One interesting thing I noticed about WordPress 2.0 was the built-in caching features do work but it’s still significantly slower than using the WP-Cache plugin. The average load time of my blog homepage went from 0.3 seconds to over 1 second.

After reading what I just wrote, I guess the title is a little misleading as most, if not all of the issues were caused by me. 🙂 But there are people that are having some issues upgrading to WordPress 2.0 and so I think I will wait for the 2.0.1 release which is coming soon. Kudos to Matt, Ryan and the rest of the WordPress team on another great release of software that just works.

mysql, wordpress, wordpress2.0, upgrade, kattare, dns, isp, blog, sql, java+hpsting, jsp+hosting, tomcat, GrabPERF, performance, monitoring