Error establishing a database connection: solved

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 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 DigitalOcean 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:

  1. Seeing the “Error establishing a database connection” error; and
  2. Seeing many entries in the web server logs of the kind:
    “POST /xmlrpc.php HTTP/1.0”.

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.


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!


My site has been up and running again for a good few days now, without the error happening again. The error has been resolved.

Do you want to reply?

This site uses Akismet to reduce spam. Learn how your comment data is processed.