I’ve been meaning to do this for a while, but a slashdot linked article about the large number of insecure PHP installs in the world got me off my ass to upgrade my stock Mac OS X php install from 5.3.x to 5.6.x. Thankfully, the process was pretty painless with the scripts provided here.
I did have to modify my http conf (since I’m not running a stock Apple install) to point to the new php, as well as set the new install location in my .profile, both of which were pretty easy. The biggest annoyance with the upgrade to PHP 5.6, however, was having to fix anywhere where objects were being set via reference “=&” rather than just =. So most of my PDO DB queries were being set via “$result =& $db->query(‘select blah from blah where blah’)”. This no longer worked with 5.6, as you can only set variables that way. Why I was doing it that way is because I’m a hack, and most of my PHP is copied and pasted from previous PHP I’ve done… so that practice just spread throughout. *shrugs* I also had to adjust some settings relating to APC no longer being supported, and opcache being the new PHP object cache setup. The real big change is, since I use W3TC, I had to DISABLE the Database and Object caches. Since these rely on no-longer supported APC calls, things would work fine for about an hour, then WordPress would just stop responding altogether (guessing when it would try to issue a garbage cleanup call) ((Sadly, the author of this plugin has been rather quiet about adding Zend opcache support)). Interestingly, my site sped up significantly after this change. Cool.
Since my server is a Mac, I had already been running MySQL 5.6 for some time (since OS X doesn’t ship with MySQL anymore), but I wanted to take this opportunity to “upgrade” all my tables from MyISAM to InnoDB. This, actually, was a bit more of a pain than I thought it would be.
The weirdest thing is that when I went to convert my power readings log (which has over 3 million rows), I had two instances of duplicate primary_keys. I guess MyISAM let something slip through the cracks, but InnoDB re-creating the DB stopped that cold. Also, I realized I hadn’t had a my.cnf being referenced in quite some time, so everything was set from default. Oops. So I created a new my.cnf, but that brought about another issue. Mac OS X has insanely low defaults for Max Files open meaning the my.cnf I had created with it’s 8000 max tables, was hitting that limit rather quickly. The fix for that was outlined here, and here. Basically I upped the limit to 65000 open files. That should solve the issue. The annoying part of that issue was that MySQL was failing relatively silently, and because the tables for this site are the “last” it loads, it wouldn’t load some of them, and the site would just timeout. =/
Also of note, if you have “slow-query-log” enabled, make sure you don’t leave “log-queries-not-using-indexes” enabled, as the mysql-error.log can grow very big, very fast. In less than 24hrs, mine was well over 1GB. This is largely because of cacti that I have running. Also, it’ll slow down things on your server since MySQL will be constantly writing out to that log. =(
All and all, the process wasn’t that bad. I’ve certainly done worse upgrades.
