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

  1. Seeing the Error establishing a database connection error
  2. 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.


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.

Leave a Reply

Your email address will not be published. Required fields are marked *

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