Error establishing a database connection (WordPress)

  • Posted May 25, 2014

Hi there,

I’m having a really hard time figuring this out… My website shows up “Error establishing a database connection” on occasion. This happens about once a day. As soon as I reboot the droplet, the problem’s gone.

I’ve tried adding the following 2 lines in my wp-config file, as suggested on some other forums, but it didn’t work:

define(‘WP_MEMORY_LIMIT’, ‘64M’); define(‘WP_ALLOW_REPAIR’, true);

From what I read around the web, it seems that 512mb of RAM is perfectly fine for a wordpress multisite, if set correctly - though I’m having a hard time with a single (low content) site, without many plugins. I’ve also disabled/deleted the plugins that could potentially eat up a lot of memory, such as wp-backup.

If you have any suggestions for me, I’d be more than thankful! Please notice that I’m pretty new with all this, and as it’s my first time running VPS, I do have a bit hard time understanding how everything works, at the moment…


Hi @curiousgeorge, check out our community article here or my response in the “Answers” section below.

Hey there! We have some solutions for this issue in the Answers below. Definitely check them out, especially the replies by @kamaln7 and @nestchris, as well as my own.

We have about 20 accounts on DigitalOcean and over the past two months ALL OF THEM have been experiencing this issue, even on droplets with 4GB RAM. We’re migrating all of our sites elsewhere…

I’ve had the same problem. Tried for weeks, went through all the suggested solutions without any success. Digital Ocean support weren’t able to help either. I’ve migrated the Wordpress to another provider now, but shortly after the migration, have had the same problem there. So my current hypothesis is that Wordpress has become very memory hungry in more recent versions, and/or there’s specific memory leaks with some common plugins. I’ve just increased memory to 2GB and swap to 2GB to see if the extra headroom fixes it.

The fact that DO isn’t on threads like this helping people or making public statements about something that is so clearly not working is a huge turn off. I really enjoyed using their servers for Python web apps, but I’ll be shortly migrating everything somewhere else. I’d honestly rather give my money to godaddy at this point since my sites at least worked there.

Same problem here on both of my sites!! Will be migrating my sites to another provider and closing my D.O account tomorrow.

It has happened to me on at least two occasions in the last week or so. Have to say that I hadn’t had that issue when I was with Ramnode.

Same problem here.

I had the exact same thing. Switched Wordpress over to AWS hosting and the site has been stable since.

Also having the same issue. This happens fairly frequently

Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

EDIT: If you’re fairly certain you’re not suffering from an xml-rpc attack, check out our article about debugging Wordpress database errors.

EDIT: We now have a community article covering xml-rpc attacks!

Hey there,

As @nestchris said, we have started seeing an influx of brute-force amplification attacks, both on our service and the rest of the internet at large. These attacks exploit the XML-RPC functionality in WordPress, as described on

You can see if you are being taken down by this attack by running one of the following two commands on your droplet, depending on which webserver you’re running:

Apache: grep xmlrpc /var/log/apache2/access.log Nginx: grep xmlrpc /var/log/nginx/access.log

If you get any results there, it should be easy to fix this issue. If you’ve spun up a WordPress One-Click install droplet since Dec 2015, there’s a small config file which you can enable to block such attacks. We don’t enable it by default because it breaks some commonly used plugins (like Jetpack). Here are the commands you can run:

sudo a2enconf block-xmlrpc
sudo service apache2 restart

Alternatively, Jetpack has functionality to block these requests without impacting other plugins. Check out their Protect module.

If you’re running a WordPress droplet older than Dec 2015 and you don’t want to use the Jetpack plugin from Automattic, you’ll need to configure the droplet manually to block requests to xmlrpc.php:

Apache2 (goes inside your VirtualHost config):

<files xmlrpc.php> 
order allow,deny 
deny from all 

Nginx (goes inside your server{} block):

location /xmlrpc.php { 
deny all; 

Alternatively, if you are not having this issue due to an XML-RPC brute force attack, your Droplet might not have enough memory to deal with your traffic reliably. We recommend users run WordPress on a 1GB droplet or larger.

In order to help reduce your memory usage, you’d first want to check for any plugins using a large amount of memory. There are a lot of memory hungry plugins out there! You may also want to optimize your configuration files.

Below are some great resources that we commonly recommend in support tickets, explaining how to do so, depending on your setup:




If none of this works, you may have no choice but to resize to a larger sized droplet that can handle your traffic.

Best, Eris Platform Support Specialist

It seems like MySQL is running out of RAM and crashing. You could add swap and see if that helps (<a href=“”></a>), or upgrade your droplet to the next plan so that there’s more RAM available for MySQL.

As we know, a shared host like Bluehost has more direct control over your server. On DO, you are required to maintain the server, and that means things that you might not need to deal with on other hosts come up here.

I was made aware of this exploit by the DO team.

After implementing the apache.config solution, my problems stopped.

[Apache VirtualHost Config] <VirtualHost> … <files xmlrpc.php> order allow,deny deny from all </files> </VirtualHost>

This attack is affecting all wordpress sites, but if you were using another host before, you may not have noticed. In my experience with Bluehost, I have had them suspend my account because I was attacked by comment spam, I suspect something similar to that would have occurred in this instance as well.

Unfortunately DO has been very slow to address this issue with the community as it seems everyone is in the dark about it.

I Have done all of these things; spoke to support who kindly suggested it ; and i am STILL getting this issue. I am thinking about leaving DO because this is a business I am running and random error establishing a connection shouldn’t be happening, especially if I go to sleep and find out at 1AM it went down and didn’t find out until I got up at 7AM! This has been going on for now three months. I also upgraded and I STILL have the issue. Please DO , fix it, I have tried on my end and it is STILL happening. I am frustrated about it. I have opened a support ticket and sill no fix.

Can someone recommend a good Wordpress host because this is a fucking disaster.

Problem solve with this code… Very simple :)

sudo start mysql

please tired all week my site falls due this connection error will not change cloud service more

I am not a real tech guy, but I was able to fix our website,, by turning off the power of the droplet and turning it on.

I have had the same problem and its not a fault of digital ocean. A little bit knowledge in server maintenance is what is actually required.

Ubuntu 14.04

Check if your mysql is running mysqladmin -u root -p status

and then enter your mysql root password

if it’s running properly u get a message Uptime: 4 Threads: 1 Questions: 62 Slow queries: 0 Opens: 51 Flush tables: 1 Open tables: 45 Queries per second avg: 15.500

or an error message

mysqladmin: connect to server at ‘localhost’ failed error: ‘Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)’ Check that mysqld is running and that the socket: ‘/var/run/mysqld/mysqld.sock’ exists!

This error message is the reason for you to get Error establishing a database connection

fix this by starting the mysql with the command sudo start mysql

I hope my solution helps you in fixing your issue.

Hello all,

This crash is most likely due to your system running out of memory. I’d suggest that you add a swap file to give yourself a bit more of a buffer. Check out this tutorial:

How To Add Swap on Ubuntu 18.04

I would recommend checking the MySQL error log to see if there was a crash. The command below will output the last 50 lines from the MySQL error log.

  1. tail -50 /var/log/mysql/error.log

If you see lines with Out of memory or Killed process, MySQL is unable to allocate the RAM it needs to continue to run and the OOM killer is killing off the process.

There are a few ways to resolve this

  • Reboot the Droplet (short-term solution to get you back online)
  • Resize your Droplet
  • Optimize the MySQL configuration (MySQL Tuner is a great tool to get you started)
  • Enable Caching for your WordPress using a plugin (W3 Total Cache works very well)

The MySQLTuner is a script written in Perl and allows you to quickly test your MySQL configuration and it gives you suggestions for adjustments to increase performance and stability.

According to the official GitHub page, it supports 300 indicators for MySQL/MariaDB/Percona Server in this last version.

To run the script you could do the following:

  • SSH to your Droplet
  • Download the script:
wget -O
  • Then execute it:

The script would run multiple checks against your MySQL instance, all checks done by MySQLTuner are documented here.

Also as stated in the official documentation, it is still extremely important for you to fully understand each change you make to a MySQL database server. If you don’t understand portions of the script’s output, or if you don’t understand the recommendations, you should consult a knowledgeable DBA or system administrator that you trust.

As a good practice make sure to always test your changes on staging environments before implementing them on your production database.

On the same note, if you want to have worry-free MySQL hosting and focus on your application, I would recommend trying out the DigitalOcean Managed Databases:


Hope that this helps! Regards, Alex