On this page:
My website broke again. It was the Error establishing a database connection error again.
Restarting the database
The first thing I did to fix it was to restart the database. This time, I used
sudo service mysql start
as suggested by Digital Ocean.
Finding possible remedies
Then I looked round the internet to see if I could find what the problem was. The main thing seemed to be that the database needed optimising. I didn’t think it could be that slow, though, given that it’s not really all that big. Nevertheless, I investigated optimising the database and the blog.
WordPress themselves have a page with lots of advice on how to optimise both blog and database. I followed some of the tips it gave.
- I used WP Optimize to optimise the database and remove unused stuff that takes up space in it. As I expected, it didn’t do a great deal of anything. I’m keeping it anyway so it can maintain my database for me.
- I looked at various caching plugins, but for one reason or another, I didn’t really like any of them.
- I signed up to CloudFlare, which claimed it would do caching and optimisation and all sorts. I had to change my DNS records, which always scares me a little bit, but it did seem straightforward in the end. And you can use their basic services for free.
- MySQL optimisations seemed beyond me.
Finding the cause and the solution
After I’d spent all that time faffing about with DNS records and strange settings, I poked around the Digital Ocean community pages to see if there was anything there about problems with WordPress database.
The cause
I found a tutorial on how to protect WordPress from XML-RPC attacks. I thought I might as well give it a go.
The first step was to see if it was actually an XML-RPC attack. There are two symptoms:
- Seeing the Error establishing a database connection error
- Seeing many entries in the web server logs of the POST /xmlrpc.php HTTP/1.0 kind.
Well, I certainly had the first one, but what about the latter? I don’t know how to view access logs. Luckily, the tutorial assumed I wouldn’t. After connecting to the server on the command line via ssh, I typed:
sudo grep xmlrpc /var/log/apache2/access.log
because I have an Apache server.
This resulted in lines and lines of output, similar to the following, spewing forth:
111.222.333.444:80 555.666.777.888 - - [01/Jan/2016:16:33:50 -0500] "POST /xmlrpc.php HTTP/1.0" 200 674 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
This confirmed my server was being hammered by a brute force attack using XML-RPC. Next step: preventing it from happening again.
Prevention
So, how can I prevent this from happening? The first thing they list is to install the Jetpack plugin. You need a WordPress.com account to use it.
I’ve used the Jetpack plugin before, but I decided I didn’t like it, for some reason. It was so long ago, I can’t remember why. I installed the plugin, and ensured that the Protect setting was enabled.
I paused the CloudFlare service to see if I stopped seeing the database connection error; I did. So the overcomplicated CloudFlare thing was perhaps a waste of time, but at least it’s free. Having said that, I have unpaused CloudFlare again. Might as well use it, seeing as I have it!
Result
My site has been up and running again for a good few days now, without the error happening again. The error has been resolved.
