Migrations pains
I originally wanted to call this post, Why you should backup your database so you don’t have to stay up until 4:00 am manually fixing records, but the damn title wouldn’t fit…
In an attempt to finalize the blog migration from my old server (that I started 4 months ago) I decided it would be a good idea to import all of my old posts into the new database. Unfortunately there isn’t a built in Mephisto –> Mephisto convertor, which almost allowed me to give up and go back to the couch and watch a movie, that is until one of the damn voices in my head kicked in…
- Hey!
- What?
- You call yourself a developer!? Get off your butt and write a script to finish this thing.
- But the couch looks so comfy, and I’ve been working all day…
- Don’t give me that crap, do it!
- Sigh. Fine.
So I grabbed another beer^H^H^H^Hsoda and started looking through the schema and example convertors. At first I thought I could just do a simple SQL dump and import. I quickly realized that this wouldn’t work as the new server was configured in a multi-site setup with lots of existing posts and the old foreign keys wouldn’t match up. I then spent about a half-hour staring longingly at the couch, pissed at my new-found motivation, when I realized that all I’d have to do is open two db connections, one to the old database and one to the new one. I would then be able to use ActiveRecord to query the existing objects and create records.
I figured that this would be a good opportunity to try out Dr. Nic’s Magic Multi-Connections library which got a bit of press during the whole Twitter scaling debate. Supposedly with this library I could open two unique database connections for a single ActiveRecord class, which is exactly what I needed to do.
After a quick glance at Nic’s examples I threw together a little script which appeared to do what I wanted. A couple runs on my local server proved everything was working great. I then copied everything over to production, and crossed my fingers as I typed ruby lib/convert.rb (try typing with your fingers crossed some time, its harder then you’d think). Everything appeared to work fine, but just to be sure I hopped into console and did a quick Site.find(3).articles.count. What should have returned 46 returned a number well over 200. Shit.
For some reason this magic library decided it didn’t want to open the 2nd connection, so instead of copying from my archive database it decided to copy all of the articles, from all of the sites, on the production server. Sigh.
I then spent the next hour in script/console working some magic to weed out all of the articles that had common titles/creation-dates so that I could try and get things back to the original state. Luckily I was able to get things reverted, and I didn’t effect anyone else’s data. Things could have been worse.
So kids the moral of this story is always backup your production database before getting in there and mucking around, especially when you are using libraries that you aren’t familiar with. Also, when one voice says hit the couch cause its 2:00 am and it’s time to watch a movie, perhaps you should listen…
Oh and I almost forgot; I did end up getting the script fixed, and all old posts have been migrated. Only problem is I was previously prefixing all permalink urls with “/articles” so the links are still broken, but the content is there. I will bust out some regex tomorrow and write a redirect for the old links, until then everything should be available via the archive or search.
