Error establishing a database connection (WordPress)

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

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 Securi.net

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 
</files>

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:

Apache: https://www.digitalocean.com/community/tutorials/how-to-optimize-apache-web-server-performance https://github.com/gusmaskowitz/apachebuddy.pl

Nginx/php-fpm: https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration http://blog.chrismeller.com/configuring-and-optimizing-php-fpm-and-nginx-on-ubuntu-or-debian

MySQL: http://mysqltuner.com/ http://www.percona.com/blog/2014/01/24/mysql-server-memory-usage-2/

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

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 Securi.net

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 
</files>

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:

Apache: https://www.digitalocean.com/community/tutorials/how-to-optimize-apache-web-server-performance https://github.com/gusmaskowitz/apachebuddy.pl

Nginx/php-fpm: https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration http://blog.chrismeller.com/configuring-and-optimizing-php-fpm-and-nginx-on-ubuntu-or-debian

MySQL: http://mysqltuner.com/ http://www.percona.com/blog/2014/01/24/mysql-server-memory-usage-2/

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

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 Securi.net

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 
</files>

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:

Apache: https://www.digitalocean.com/community/tutorials/how-to-optimize-apache-web-server-performance https://github.com/gusmaskowitz/apachebuddy.pl

Nginx/php-fpm: https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration http://blog.chrismeller.com/configuring-and-optimizing-php-fpm-and-nginx-on-ubuntu-or-debian

MySQL: http://mysqltuner.com/ http://www.percona.com/blog/2014/01/24/mysql-server-memory-usage-2/

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

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 Securi.net

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 
</files>

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:

Apache: https://www.digitalocean.com/community/tutorials/how-to-optimize-apache-web-server-performance https://github.com/gusmaskowitz/apachebuddy.pl

Nginx/php-fpm: https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration http://blog.chrismeller.com/configuring-and-optimizing-php-fpm-and-nginx-on-ubuntu-or-debian

MySQL: http://mysqltuner.com/ http://www.percona.com/blog/2014/01/24/mysql-server-memory-usage-2/

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

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 Securi.net

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 
</files>

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:

Apache: https://www.digitalocean.com/community/tutorials/how-to-optimize-apache-web-server-performance https://github.com/gusmaskowitz/apachebuddy.pl

Nginx/php-fpm: https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration http://blog.chrismeller.com/configuring-and-optimizing-php-fpm-and-nginx-on-ubuntu-or-debian

MySQL: http://mysqltuner.com/ http://www.percona.com/blog/2014/01/24/mysql-server-memory-usage-2/

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

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 Securi.net

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 
</files>

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:

Apache: https://www.digitalocean.com/community/tutorials/how-to-optimize-apache-web-server-performance https://github.com/gusmaskowitz/apachebuddy.pl

Nginx/php-fpm: https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration http://blog.chrismeller.com/configuring-and-optimizing-php-fpm-and-nginx-on-ubuntu-or-debian

MySQL: http://mysqltuner.com/ http://www.percona.com/blog/2014/01/24/mysql-server-memory-usage-2/

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