It’s the time of the month where I check the sites and workstations I manage. It’s when I purge the log files (which I review weekly), delete old backup files, run fsck, update my admin scripts, and go through my security checklist.
Then I noticed something odd. I can’t seem to login to my blog (this blog). Oh I can view it alright, but every time I try to login, the WordPress script kept on spitting the error establishing a database connection message. My ping script failed to go off because, technically, my blog didn’t go down.
So I tried to dig deeper, verified and double-checked that my database credential’s correct. I successfully logged in manually. A database script that I created for this purpose was successfully authenticated. I triple-checked my user settings and MySQL logs to no avail. Then I tried to copying the whole file, dump the database (using PHPMyAdmin) and insert the database to my workstation with the same results.
But only when I tried dumping manually did I notice that one of my table had a problem:
..is marked as crashed and last (automatic?) repair failed when using LOCK TABLES
Aha! I found the slippery critter! And then I realized, the last power interruption we had that could’ve brought down my server (my UPS could only handle 15mins) and possibly crashed my tables was over three weeks ago. So that means WP Super Cache kept my site up for almost a month. Woah!
So here’s what I learned from this ordeal:
- Never put too much faith in PHPMyAdmin, do it manually next time.
- Remember # mysqlcheck -u root -p -A –auto-repair
- Install WP Super Cache, donate if you can
At the same time, WordPress developers needs to figure out how to create a more descriptive database errors for this kind of issue.