Testing testing… this thing on?
Once you’ve configured db-config.php and copied both files into the relevant places, HyperDB should just magically work. But how can we test if it does?
Easy: open your browser and (hopefully) see your website in full glory. Now head over to your SSH terminal and switch one of the masters off – all we need to do is stop the MySQL daemon with this shell command:
service mysqld stop
Refresh your browser and see if the site is still alive. If it is, go switch off another server, and another, until none of them are active anymore. Only then will your website eventually time out. In this situation you can really see how long HyperDB tries to get in touch with another active server. It’s pure genius!
Switch those daemons back on with
service mysqld start
and bring your website back to life. It deserves it 😉
Note: on one of my sites HyperDB just didn’t want to spring into action – it blatantly ignored my server configuration and only looked at one database server. It took me a while to figure out that the file ownerships were not set correctly for pretty much all files on that site. I had to chown this back to the site owner, then everything worked as expected.
There’s another way to test if HyperDB is active or not: head over to your Plugins and take a look at the list of Active, Inactive and Drop-Ins. db-config.php should appear as a custom database class, which indicates that it’s active.
Drawbacks
As excited as I am about the idea of using this in a production environment, my preliminary test results have shown a distinctive lag in site performance. I’d assume that with more servers at my disposal the site would become even speedier.
In reality I guess HyperDB spends quite some time checking server speeds every time it sends a query and evaluates results. I’m not sure if I like it. I’ve tried declaring one server for writes only, and two for reads only, but the backend lag hasn’t improved. More tinkering is in order I think.
Conclusion
HyperDB is fantastic, and it’s relatively easy to add to any existing WordPress site. The super tough part is getting the MySQL replication going – which is not for the fainthearted. Without it HyperDB can’t operate, so you really need both for this to work.
I’m concerned about the reduction in response time compared to my dual-server setup as it was lightning fast before. That may just be me being picky or some configuration needs to be tweaked.
HyperDB does not make sense unless you have two or more physically different servers. You could run it with several virtual machines of course, but you’ll still have a single point of failure right there. HyperDB is not for casual websites, but rather an add-on to make WordPress become high-availability-aware.
If you’re on a shared hosting environment with a cheap plan, or you’re not sure what MySQL is, this tool is not for you.
7 thoughts on “How to deploy HyperDB”