Error establishing database connection is my most hated WordPress problem – it’s so cryptic and so many things can cause it. I run about a dozen WordPress blogs: some are on shared hosting, some are on virtual private servers (with Digital Ocean), and nearly all of them have had this problem at some time or another. This article documents what I do when it happens to me.
If it’s any comfort, I’ve never not solved this problem (eventually). It’s definitely fixable, but there are a lot of things that can cause it, so if nothing here helps you just keep digging around in the Googles – and good luck.
Before you do anything, turn on error messages and see what the problem actually is
Get into your website’s files, either through FTP or your host’s control panel, and turn on debug mode in wp-config.php. This file is in your WordPress installation directory.
Change this line to true:
define('WP_DEBUG', true);
Now go back to http://sitename.com/wp-admin and get those juicy error messages.
This step alone can save you a lot of frustration as you debug the actual cause of your WordPress blog’s Error Establishing Database Connection problem.
Possible fix #1: make sure DB_USER and DB_PASSWORD match what your host has
The vast majority of the times I run into Error Establishing Database Connection on a shared hosting site, it’s because something (I don’t know what) caused the DB_PASSWORD in wp-config.php to become out of sync with the password my host has for that user. This particular flavor of the error connecting to db problem seems to only affect my sites that are on shared hosting (most recently, it happened to a site I host on lunarpages.com).
Basically, what wp-config.php has for DB_USER and DB_PASSWORD has to match what your host has saved for that database and particular user.
By turning on WP_DEBUG in step 2, I was privy to the following error messages when attempting to access http://mysite.com/wp-admin:
Warning: mysqli_real_connect(): (HY000/1045): Access denied for user 'x2_artblog'@'localhost' (using password: YES) in /home/x2/public_html/blog/wp-includes/wp-db.php on line 1488 Warning: mysql_connect(): Access denied for user 'x2_artblog'@'localhost' (using password: YES) in /home/x2/public_html/blog/wp-includes/wp-db.php on line 1518
If this looks like your problem, then for some reason, your WP database login credentials are fubar.
The credentials it’s trying to use are in wp-config.php (keep this file open, the following steps will help you fix it):
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'x2_artblog');
/** MySQL database username */
define('DB_USER', 'x2_artblog');
/** MySQL database password */
define('DB_PASSWORD', '123xyz456abc');
If you know what your DB_USER and DB_PASSWORD are supposed to be, maybe you’ll spot a discrepancy here. Chances are, you don’t know what’s supposed to go here, so you can’t tell just by looking if it’s right. That’s okay, I don’t either, but it’s easy to get everything matching.
First, if you have CPanel on your host, you can log into CPanel and go into MySQL Databases to see a list of users associated with your database(s).
Next, find your database and look in the Privileged Users column. One name from the Privileged Users column has to match the username given in wp-config.php.
If the user your wp-config.php file is expecting is already in this column, you’re good to go to the next step where you reset its password.
If you don’t have the same user your wp-config.php expects, either add that user here or change wp-config.php to reference a user you do have.
Still on the MySQL Databases page, scroll down into “Current Users” and find the user your db is using. Click Set Password.
I just change the user’s password to something randomly generated, it doesn’t matter. Copy that password and paste it right into wp-config.php
/** MySQL database password */
define('DB_PASSWORD', '123xyz456abc');
Save wp-config.php (and upload it via FTP if you aren’t doing this edit directly through your hosting CPanel).
Try the site again: if it works now, you’ve resolved your “access denied” error and may now have full access to your WordPress site again.
Possible fix #2: it could be a bad plugin
This one is easy to test the fix for but I’ve only seen it be the problem once, and it happened right after I messed with plugins so the cause was obvious. However, with more plugins and WP things going to “auto update” these days, I could see how this might crop up independent of blog-owner interaction.
Rename the plugins folder.
I log into my site’s file manager via my hosting service’s website or FTP, navigate to /wp-content and rename the folder called plugins. (Don’t delete it, just put an X at the end or something.)
plugins > pluginsX
Try the site again – if it loads, your problem is one of your plugins. You can narrow it down by renaming plugins back to its normal name and then turning plugins off in groups to narrow it down to a specific one.
If your site doesn’t load, put plugins back to normal and go to the next step.
Possible fix #3: maybe your MySQL service croaked – try restarting it
This particular flavor of “Error Establishing Database Connection” seems to affect my Digital Ocean (VPS) hosted blogs (not my shared hosting blogs). There are many reasons why MySQL can crash, but when your WP site is down and you’re losing money by the hour, getting it back online is probably your #1 priority.
Since my Digital Ocean hosting runs on Linux, I log in to the virtual console and check if mysql is running with this command:
mysqladmin -u root -p status
This command brought MySQL back up:
service mysql start
Now, as to why it crashed in the first place, that could be any number of things, and chances are, MySQL will go right back down again as soon as the same conditions return.
The various fixes I’ve applied in effort to stop chronic MySQL crashes on Digital Ocean merit their own article someday, but for the sake of helping anyone who might find this, here’s a brief overview of stuff I’ve done on my VPS WordPress to try to stop frequent MySQL crashes.
I tried to figure out what was using up memory by logging into my droplet’s virtual console and looking at all the active processes sorted by what resources they are consuming. The command to see that chart is top.
Here’s the steps to sort what’s in top by memory usage:
top f key arrow down (to highlight %mem) s key (to select %mem) escape key (to return to process list)
You should now see your process list sorted with the most memory intensive processes at the top. What you find here will help you Google for solutions.
For me, mysqld is always at the top, soaking up all the memory, so I focused on that when I was trying to fix chronic “Error Establishing Database Connection” problems on my Digital Ocean WordPress blog. After mysqld was always a whole ton of apache2 instances.
Some of the stuff I did…
Went into apache2.conf and added this code to help protect against brute force attacks:
<files xmlrpc.php> order allow,deny deny from all </files>
This alone did not stop MySQL crashing, it crashed a few weeks later. So then I did…
I edited /etc/my.cnf to increase buffer pool size and set max_connections to 200 (this line was commented out, previously).
## Edit /etc/my.cnf, and add the following line under the [mysqld] heading. [mysqld] innodb_buffer_pool_size=64M
These fixes also did not stop it, but I had another few weeks of uptime following them.
I edited /etc/apache2.conf, changing maxKeepAliveRequests from 100 to 9 because it seemed like a good way to limit how much memory apache was allowed to take up. Be sure to run service apache2 restart after editing to apply changes.
Restarting the droplet has helped, too. One time I cleared my blog’s MaxCDN cache and that immediately took the site down and replaced it with Error Establishing Database Connection. When that happened, restarting the droplet brought it back up.
To be honest, MySQL crashes on Digital Ocean are kind of an ongoing issue for my most popular WordPress blog, but I’ve managed to lengthen the time between crashes/restarts with the above steps.
Even more help with WordPress db error (articles, threads, etc)
WPBeginner has the Internet’s de facto go-to article on the subject, and they also report that somehow the database credentials on their shared host site got reset. They also have some solutions I’ve never had work for me but are worth looking into if nothing in this article worked for you.
This thread has plenty of one-off posters coming in to share their various fixes for the problem and is also worth a look if you’re stuck.
Oh, and be sure to put this line in wp-config.php back to false:
define('WP_DEBUG', false);
