Support Hub

Error Establishing Database Connection

  • Updated

If you've recently attempted to load your WordPress-powered website and instead saw a message stating "Error Establishing Database Connection", the cause is most often one of the following:


  • The database service has crashed, often due to the server running out of memory
  • The servers Disk is full
  • The database login credentials are incorrect in your WordPress configuration
  • The WordPress database tables have been damaged


Let's walk through these issues one at a time to determine if they affect you, and how to fix them.


Step 1 — Check if MySQL is running


A good starting step for debugging this problem is to try logging into the server to see if the system is healthy and MySQL is running. As a first step, it would be worth trying to restart the database service. You can quickly do this via our hosting platform, see the guide below:


You can check and restart the database service via SSH. You can find your SSH login details using this guide. Log into your server via SSH, remembering to replace the highlighted portions below with your own user and server details:


  • ssh username@your_server_ip


Note: If you’re sure you have your connection details correct but you're still having trouble logging in, it could be that your server is out of memory or under very heavy load. This could be due to a sudden burst of traffic to your website, and would explain the WordPress error. You may need to restart your server before you'll be able to log in which is covered in this guide.


Now that we've logged in successfully, let's check that our MySQL server is running:


  • systemctl status mysql


The sysctl command is usually used for starting, stopping and restarting services but can also print the services current status. Check the output for a line listing mysql as Active:


mariadb.service - MariaDB 10.1.34 database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/mariadb.service.d
   Active: active (running) since Mon 2018-07-30 08:03:36 BST; 3 weeks 2 days ago
     Docs: man:mysqld(8)
 Main PID: 1547 (mysqld)
   Status: "Taking your SQL requests now..."
    Tasks: 29
   Memory: 202.6M
      CPU: 16min 55.799s
   CGroup: /system.slice/mariadb.service
           â””─1547 /usr/sbin/mysqld

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.


If your output is similar, we know MySQL is running and listening for connections. If you see MySQL listed as inactive, try starting MySQL manually. On most systems that would look like this:


  • systemctl start mysql



MySQL should start. To verify, rerun the status command we used above, and check the output for the Active line.


If MySQL still isn't running there may be another issue such as the Servers disk being full or some of the Databases tables may be crashed and stopping the service from starting.


MySQL and WordPress both need a good amount of memory to run properly. If MySQL has quit due to a low memory situation.


You may be temporarily experiencing unusual traffic. If there are many error lines, your server is regularly becoming memory constrained. Either way, the solution is to upgrade to a server with more available memory or it can sometimes be resolved via putting your site(s) behind Cloudflare.


Step 2 — Check Free Disk Space


A common cause of an Error Establishing Database connection and the MySQL service being stopped can be the servers disk being 100% full as the service won't be able to create any temporary files it needs for normal operation.


You can easily check you disk usage via our hosting platform, it is displayed when viewing your servers. If it is full, you'll want to clear some space or look to upgrade to get more disk space. See the guides below:


You can also check this via SSH. The easiest way of checking this is to issue this command:



  • df -h


and the output should look similar to below:



Filesystem                         Size  Used Avail Use% Mounted on udev                               975M     0  975M   0% /dev tmpfs                              200M   24M  176M  12% /run /dev/mapper/ubuntu--base--vg-root   33G  3.1G   28G  10% / tmpfs                              996M  4.0K  996M   1% /dev/shm tmpfs                              5.0M     0  5.0M   0% /run/lock tmpfs                              996M     0  996M   0% /sys/fs/cgroup /dev/xvda1                         472M  110M  339M  25% /boot tmpfs                              200M     0  200M   0% /run/user/1003


In this example the one you want to pay attention to is the 33G partition, generally it will always be the largest partition you want to make sure has free space.


If the drive is 100% full you will need to try and clear some space to get back up and running again, the easiest way is to clear some log files, these logs are safe to clear:



  • /home/storm/logs/SITENAME/
  • /var/log/


It's best to clear out the archived logs in /var/log first by issuing this command:



rm -rf /var/log/*.gz


Other than those files you would need to audit your website(s) to see what their file usage is and clear some files from them, in the Nimbus Hosting platform you can see the current space usage on the Server Dashboard, Click on  Disk usage and it will take you to a page with a breakdown:



Around 3GB~ will already be used due to system files.


If the disk isn't full and MySQL still won't start it may be that the server has ran out of Inodes:


What are inodes?


An index node (or inode) contains metadata information (file size, file type, etc.) for a file system object (like a file or a directory). There is one inode per file system object.

An inode doesn't store the file contents or the name: it simply points to a specific file or directory. So if your site isn't clearing sessions correctly they can build up and eventually use all of the Inodes.


You can check how many Inodes are available by using the following command:



  • df -i


which should output something similar to this:



Filesystem                         Inodes  IUsed   IFree IUse% Mounted on udev                               249503    452  249051    1% /dev tmpfs                              254770    609  254161    1% /run /dev/mapper/ubuntu--base--vg-root 2125040 120024 2005016    6% / tmpfs                              254770      2  254768    1% /dev/shm tmpfs                              254770      7  254763    1% /run/lock tmpfs                              254770     16  254754    1% /sys/fs/cgroup /dev/xvda1                         124928    310  124618    1% /boot tmpfs                              254899      4  254895    1% /run/user/1003


You want to be checking the same partition as above for that you did for Disk space, if there are 0 inodes free you will need to clear some files as all files use Inodes.


If you're not able to clear any space you will need to contact support or raise a ticket to get extra disk space added to your server.


Step 3 — Check Database Login Credentials


If you've just moved your WordPress install between servers or hosting providers, you might need to update your database connection details. These are stored on the server in a PHP file called wp-config.php.


First, let's find our wp-config.php file, if you connect to your site via ftp you can find your FTP login by using this guide


You'll need to open the file in an editor, we recommend Notepad++ or just normal Notepad will be fine.


In the wp-config.php you'll be looking for these lines:


/** The name of the database for WordPress */
define('DB_NAME', 'database_name');

/** MySQL database username */
define('DB_USER', 'database_username');

/** MySQL database password */
define('DB_PASSWORD', 'database_password');


Check that these three variables are correct based on the information in the Nimbus Hosting platform. If they don't look right, update as appropriate, save and exit the file then upload it back using FTP.


Reload your website to see if the error is gone.


Still not working? The next thing to try is repairing the database.


Step 4 — Check and Repair Database tables


Again, this is super easy via our platform. See the guide below:


You can also do this via SSH. For this you'll need to connect to the server.


Once done you will need to switch to the root account and issue the following command which will run through all the databases on the server and if any crashed tables are found it will repair them:



  • mysqlcheck --all-databases --auto-repair


Once ran you will need to restart MySQL to get it back up and running:



  • systemctl start mysql


These are the most common reasons you will be getting the Error Establishing a Database connection, if you're still having issues after running through this document you will need to contact support or raise a ticket to get assistance from Support.