Tutorials How to fix common problems with MySQL databases

How to fix common problems with MySQL databases

A big part of the content on the Internet is stored on databases for which MySQL is a popular choice. But what to do when suddenly your dynamic content doesn’t load, or when returning to your website you are greeted by a nearly empty white page with message “Error establishing a database connection.” This guide is aimed at helping with troubleshooting MySQL databases on cloud servers, and by following the steps listed here you’ll hopefully be able to restore your database functionality.

Test hosting on UpCloud!

Check that the service is running

If your website cannot connect to your database, it is possible the service is simply not listening. Check your MySQL state, on Ubuntu and Debian systems this can be done with the following command.

sudo service mysql status

CentOS and other Red Hat variants use MySQL as well, but it is named MariaDB instead, so use this command instead.

sudo service mariadb status

The output from the status check on CentOS and Debian will show something along the lines of this example from CentOS below, Debian output would be nearly identical with the exception of different service name.

mariadb.service - MariaDB database server
    Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled)
    Active: active (running) since Wed 2015-08-05 11:53:38 EEST; 3h 23min ago
  Main PID: 2451 (mysqld_safe)
    CGroup: /system.slice/mariadb.service
            ├─2451 /bin/sh /usr/bin/mysqld_safe --basedir=/usr
            └─2609 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql...

The printout is rather verbose, but the important part is usually coloured to stand out better. In green ‘active (running)’ means the service should be running normally if instead, it says ‘active (exited)’ or ‘inactive (dead)’ the process has been stopped or killed.

Ubuntu condenses the same information to a one-liner like an example output underneath.

mysql start/running, process 5897

If your service status says something other than ‘running’, try to restart the process using the same service command as before but with ‘restart’ instead of ‘status’.

sudo service mysql restart

sudo service mariadb restart

Should the database service restart without encountering errors, you can try to connect to it using the command below. Enter the root password when prompted.

mysql -u root -p

If you are greeted with “Welcome to the MySQL/MariaDB monitor” the connection was successful and the database service is running. If instead, you get an error like this example below you probably mistyped the password for root user. Try again, or if you are not sure about the root password, log in with another user account you have access to by just replacing root with the other username.

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

If you have your database set up on a separate server from your web host, make sure the two servers can reach each other. You can test the database connection from your web server with the command underneath using the correct username for your installation.

mysql -u <user name> -p -h <database server private IP>

Check the configuration

When MySQL is running but your website still doesn’t load as it should, or if when attempting to connect to your database manually you get an error message like the one below, you should take a look at the service configuration.

ERROR 2002: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (111)

On Debian and Ubuntu servers the configuration file for MySQL is usually saved at /etc/mysql/. It’s also possible to have user-specific settings stored at /home/<user>/.my.cnf, which would override the global configurations. Check if any user level overrides have been set. It is commonly advised to have separate usernames for different web applications, so check at least those relevant to your page loading issues. You can open the global configuration file with first of the following two commands below, and the user-specific with the latter by replacing the <user> with a database username.

sudo nano /etc/mysql/my.cnf

sudo nano /home/<user>/.my.cnf

By scrolling down past [client] and [mysqld_safe] settings you’ll find something like the example here.

# * Basic Settings
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address            =

With CentOS and other Red Hats, the primary configuration file is stored at the slightly different location, open it for inspection with

sudo vi /etc/my.cnf

The lines here to pay close attention to are ‘socket’, ‘datadir’ and ‘bind-address’. The parameters in the example above are in their default values, and in most cases, your configuration would look the same. Make sure the settings point to the correct directories so that MySQL can actually find the required files. The easiest way to check the ‘datadir’ is to use this command below

sudo ls -l /var/lib/mysql/

The output will list all files in that directory, it should contain at least the following plus any databases you have created.

drwx------ 2 mysql root      4096 Aug  5 12:23 mysql
drwx------ 2 mysql mysql     4096 Aug  5 12:29 performance_schema

If the data directory or socket has been moved and MySQL doesn’t know where they are, fix the configuration file to point to the correct directories. You can search for the folders with the following command.

sudo find / -name performance_schema  && sudo find / -name mysql.sock

The third parameter you’ll need to check is the bind-address, this is only really relevant if your database needs to be accessed remotely. In Debian and Ubuntu installations the bind is by default set to the loopback address, which prevents database calls from outside the localhost. CentOS doesn’t have the same parameter unless manually set. For any setup where your web service is on a different server to the database, this bind-address should be set to the server’s own private IP.

Check the error logs

If the configuration seems correct and the service is running, but your website still doesn’t load as it should, try checking the logs for any hints to as what might be the cause.

Debian and Ubuntu servers store error logs to /var/log/mysql/error.log. You can read through the logs with ‘less’, but this might not be very convenient as the log includes more than just critical errors. Instead, search the logs using ‘grep’.

sudo grep -i error /var/log/mysql/error.log

Should you not be able to find anything within the most recent logs, check the archived ones as well. To do this, use ‘zgrep’ with otherwise the same command as regular ‘grep’

sudo zgrep -i error /var/log/mysql/error.log.1.gz

Since the database under CentOS is named MariaDB instead of MySQL, the logs are also saved under a different name. You can search the logs with the following command.

sudo grep -i error /var/log/mariadb/mariadb.log

Debian systems also report MySQL events to /var/log/syslog, to filter out everything else, use ‘grep’ with two keywords separated by .* to express ‘and’ like in the command below.

sudo grep -i -E 'mysql.*error' /var/log/syslog

If you are having difficulties finding anything helpful, try different keywords such as ‘start’ to see when the service was last restarted, or ‘failed’ to find any less critical problems that might not be reported as errors.

Ask for help

Optimistically by now your database should be up and running again, but in case you’ve encountered a more persistent error, feel free to ask for help. Contact our support team and try to explain the problem to the best of your ability, also include the steps you’ve taken with their results while troubleshooting the issue. This will help the team in helping you with the problem.

Editor-in-chief and Technical writer at UpCloud since 2015. Cloud enthusiast writing about server technology and software.

4 thoughts on “How to fix common problems with MySQL databases

    1. Hi there, it seems your website cannot reach your database. This could be due to a number of issues depending on your configuration. If your database is on the same server as your web service, make sure it’s running and accessible with the credentials given to the web service. If the database is on a separate server, in addition to the aforementioned, check that the host is connected and reachable to the website server.

  1. the first command that worked was: sudo ls -l /var/lib/mysql/

    which listed:
    total 168120
    -rw-r—–. 1 mysql mysql 56 Jan 29 09:14 auto.cnf
    -rw-r—–. 1 mysql mysql 178 Feb 3 17:00 binlog.000006
    -rw-r—–. 1 mysql mysql 178 Feb 4 17:04 binlog.000007
    -rw-r—–. 1 mysql mysql 178 Feb 5 09:02 binlog.000008
    -rw-r—–. 1 mysql mysql 178 Feb 5 17:58 binlog.000009
    -rw-r—–. 1 mysql mysql 178 Feb 6 17:30 binlog.000010
    -rw-r—–. 1 mysql mysql 178 Feb 7 17:10 binlog.000011
    -rw-r—–. 1 mysql mysql 178 Feb 8 17:15 binlog.000012
    -rw-r—–. 1 mysql mysql 178 Feb 11 09:53 binlog.000013
    -rw-r—–. 1 mysql mysql 178 Feb 11 16:09 binlog.000014
    -rw-r—–. 1 mysql mysql 178 Feb 12 17:51 binlog.000015
    -rw-r—–. 1 mysql mysql 178 Feb 13 17:08 binlog.000016
    -rw-r—–. 1 mysql mysql 178 Feb 14 16:58 binlog.000017
    -rw-r—–. 1 mysql mysql 178 Feb 15 17:48 binlog.000018
    -rw-r—–. 1 mysql mysql 178 Feb 17 17:34 binlog.000019
    -rw-r—–. 1 mysql mysql 178 Feb 18 17:25 binlog.000020
    -rw-r—–. 1 mysql mysql 178 Feb 19 16:17 binlog.000021
    -rw-r—–. 1 mysql mysql 178 Feb 20 16:38 binlog.000022
    -rw-r—–. 1 mysql mysql 178 Feb 20 16:55 binlog.000023
    -rw-r—–. 1 mysql mysql 178 Feb 20 17:48 binlog.000024
    -rw-r—–. 1 mysql mysql 178 Feb 21 16:56 binlog.000025
    -rw-r—–. 1 mysql mysql 178 Feb 22 16:46 binlog.000026
    -rw-r—–. 1 mysql mysql 178 Feb 25 09:13 binlog.000027
    -rw-r—–. 1 mysql mysql 178 Feb 25 17:34 binlog.000028
    -rw-r—–. 1 mysql mysql 178 Feb 26 16:30 binlog.000029
    -rw-r—–. 1 mysql mysql 178 Feb 28 09:22 binlog.000030
    -rw-r—–. 1 mysql mysql 178 Feb 28 16:41 binlog.000031
    -rw-r—–. 1 mysql mysql 178 Feb 29 16:11 binlog.000032
    -rw-r—–. 1 mysql mysql 178 Mar 2 09:00 binlog.000033
    -rw-r—–. 1 mysql mysql 178 Mar 3 21:12 binlog.000034
    -rw-r—–. 1 mysql mysql 155 Mar 4 06:37 binlog.000035
    -rw-r—–. 1 mysql mysql 480 Mar 4 06:37 binlog.index
    -rw——-. 1 mysql mysql 1680 Jan 29 09:14 ca-key.pem
    -rw-r–r–. 1 mysql mysql 1112 Jan 29 09:14 ca.pem
    -rw-r–r–. 1 mysql mysql 1112 Jan 29 09:14 client-cert.pem
    -rw——-. 1 mysql mysql 1676 Jan 29 09:14 client-key.pem
    -rw-r—–. 1 mysql mysql 3329 Mar 3 21:12 ib_buffer_pool
    -rw-r—–. 1 mysql mysql 12582912 Mar 4 06:37 ibdata1
    -rw-r—–. 1 mysql mysql 50331648 Mar 4 06:37 ib_logfile0
    -rw-r—–. 1 mysql mysql 50331648 Jan 29 09:14 ib_logfile1
    -rw-r—–. 1 mysql mysql 12582912 Mar 4 06:37 ibtmp1
    drwxr-x—. 2 mysql mysql 187 Mar 4 06:37 ‘#innodb_temp’
    drwxr-x—. 2 mysql mysql 143 Jan 29 09:14 mysql
    -rw-r—–. 1 mysql mysql 25165824 Mar 4 06:37 mysql.ibd
    srwxrwxrwx. 1 mysql mysql 0 Mar 4 06:37 mysql.sock
    -rw——-. 1 mysql mysql 5 Mar 4 06:37 mysql.sock.lock
    drwxr-x—. 2 mysql mysql 8192 Jan 29 09:14 performance_schema
    -rw——-. 1 mysql mysql 1676 Jan 29 09:14 private_key.pem
    -rw-r–r–. 1 mysql mysql 452 Jan 29 09:14 public_key.pem
    -rw-r–r–. 1 mysql mysql 1112 Jan 29 09:14 server-cert.pem
    -rw——-. 1 mysql mysql 1680 Jan 29 09:14 server-key.pem
    drwxr-x—. 2 mysql mysql 28 Jan 29 09:15 sys
    -rw-r—–. 1 mysql mysql 10485760 Mar 4 06:37 undo_001
    -rw-r—–. 1 mysql mysql 10485760 Mar 4 06:37 undo_002

    these commands resulted in:
    [[email protected] ~]$ sudo grep -i error /var/log/mysql/error.log
    grep: /var/log/mysql/error.log: No such file or directory
    [[email protected] ~]$ sudo zgrep -i error /var/log/mysql/error.log.1.gz
    gzip: /var/log/mysql/error.log.1.gz: No such file or directory
    [[email protected] ~]$ sudo grep -i error /var/log/mariadb/mariadb.log
    grep: /var/log/mariadb/mariadb.log: No such file or directory

    1. Hi James, thanks for the comment. It seems your configuration is recording the error logs somewhere else. You can check the ls -l /var/log/ directory to see where the MySQL logs are and then review them using grep or zgrep.

Leave a Reply

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


Helsinki (HQ)

In the capital city of Finland, you will find our headquarters, and our first data centre. This is where we handle most of our development and innovation.


London was our second office to open, and a important step in introducing UpCloud to the world. Here our amazing staff can help you with both sales and support, in addition to host tons of interesting meetups.


Singapore was our 3rd office to be opened, and enjoys one of most engaged and fastest growing user bases we have ever seen.


Seattle is our 4th and latest office to be opened, and our way to reach out across the pond to our many users in the Americas.