-
Please support me in the 2010 Ride to Conquer Cancer - last year we were able to raise $6.9 million for the Alberta Cancer Foundation - hopefully we can raise even more in 2010! -
Blog under the Creative Commons Attribution 3.0 License
Jun
22
(2006)
I just upgraded our TLC development/staging/small-deployment server from MySQL 4.0 to 5.0.22. I'd never upgraded a MySQL server before (always just installed a fresh copy on a new box, or updated along with MacOSX) so I wanted to do some testing before making the plunge on a deployment server. We've got a bunch of databases on that box, running everything from weblogs.ucalgary.ca to some custom apps written here.
I did a quick RTFM , but the MySQL manual recommended not jumping right from 4.0 to 5.0 using the normal upgrade process. It said to go to 4.1 first, then to 5.0. So, I did some more Googling, and realized that a full mysqldump and restore would do the trick, without requiring the milk run through 4.1.
I installed a fresh copy of MySQL 5.0.x on my desktop box, did a full mysqldump from the server using:
mysqldump -u root -p --opt -Q --add-drop-table > mysqldump.sql
That gave me a 400+MB SQL file, handy for a backup, or for migrating between copies of MySQL. I copied the file to my desktop, and ran this:
mysql -u root -p < mysqldump.sql
mysqladmin -u root -p --flush-privileges
And, it Just Worked™ – so the data should safely migrate this way. I did some testing with apps – Drupal etc… and thinks behaved as expected. It takes longer to dump/restore than just updating the MySQL server, but it's safe. And all database users and privileges were intact, so everything should hook up just fine.
Then, I did the same on the server. I killed MySQL, which was still running version 4.0. I ran the installer (both MySQL 5.0 and the StartupItem) via SSH (sudo installer…) and it took care of setting stuff up. But, the old MySQL didn't shutdown cleanly, so I had to do the unthinkable – reboot the box. I know there's a cleaner, more "official" way to clean stuff up, but the box had been up for a couple months, so a reboot wasn't the end of the world.
When the server came back up, MySQL was running as expected. Then, it was a simple. First, I told my shell to use the new copy of MySQL, then imported the data:
alias mysql=/usr/local/mysql/bin/mysql
alias mysqladmin=/usr/local/mysql/bin/mysqladmin
mysql -u root -p < mysql.sql
mysqladmin -u root -p --flush-privileges
And all of our apps are up and running on a shiny new copy of MySQL. The previous version of MySQL is still on the server (but not running) with all data still safe in its own directory, so if something catastrophic has happened, reverting will be trivial.
Now, to upgrade my copy of Moodle to 1.6, which is what prompted the whole MySQL upgrade process in the first place…
Darcy,
I have to say that your habit of blogging through the technical elements of your work is extremely useful. Especially, since you are always tinkering and you have a knack for explaining the step-by-step quite clearly.
In fact, your play-by-play with Drupal has been wonderful in terms of getting a sense of what this CMS can do. I read in a previous blog post that you all had looked at a few CMSs and it came down to Joomla and Drupal –was Typo3 in the mix at all? And if so, why did you guys can it?
Jim – glad my braindumps are helpful. Be sure to take them with a grain of salt though – I’m usually just stumbling around in the dark, and use these posts as a breadcrumb trail in case I need to find my way back out… I’m quite sure there are better/faster/cleaner solutions to just about everything I put together, but it works for me…
I did look at Typo3, and it is pretty capable – likely as capable as Drupal or Joomla. For me, it came down to comfort. I’d been playing with Drupal for a while, and Joomla to some extent, and knew pretty confidently that those apps could be readily adapted for the wide variety of use cases on campus, and retain some pretty easy enterprise-scale management. Both Drupal and Joomla are already used on campus by some departments and faculties, so there’s a comfort level there. Typo3 is used in only 1 place on campus (that I am aware of), so would have taken more effort to bring people up to speed on it.
I wound up picking Drupal for our own department projects because of the flexibility, clean code, awesome development community, and maturity of the whole Drupal ecosystem. As well, the momentum and direction of the Drupal app and frameworks aligns pretty nicely with what I’ve been thinking about for the past couple of years.
If I were to evaluate Drupal 4.6 against Joomla and Typo3, it would have lost. But 4.7 has been revamped pretty comprehensively, and the stuff planned for 4.8+ is pretty awesome.
Darcy,
Nice to know the future of Drupal looks bright. in fact, here at UMW we are experimenting with all three. Andy Rush with Joomla, Patrick Gosetti Murray-John with Drupal and I am taking on Typo3. So, we can learn a ton from your selection process at Calgary. I'll have to see how Typo3 4.0 stacks up against the upcoming Drupal version, but I have heard that the online Drupal community is second to none, which ultimately could make all the difference.
Thanks for making Calgary's processes accessible for all of us to learn from …