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.<\/p>\n\n\n\n

mysql -u <user name> -p -h <database server private IP><\/pre>\n\n\n\n
Check the configuration<\/h2>\n\n\n\n
When MySQL is running but your website still doesn\u2019t load as it should, or 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.<\/p>\n\n\n\n
ERROR 2002: Can't connect to local MySQL server through socket '\/tmp\/mysql.sock' (111)<\/pre>\n\n\n\n
On Debian and Ubuntu servers the configuration file for MySQL is usually saved at \/etc\/mysql\/. It\u2019s 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 the first of the following two commands below, and the user-specific with the latter by replacing the <user> with a database username.<\/p>\n\n\n\n
sudo nano \/etc\/mysql\/my.cnf\n\nsudo nano \/home\/<user>\/.my.cnf<\/pre>\n\n\n\n
By scrolling down past [client] and [mysqld_safe] settings you\u2019ll find something like the example here.<\/p>\n\n\n\n
[mysqld]\n#\n# * Basic Settings\n#\nuser            = mysql\npid-file        = \/var\/run\/mysqld\/mysqld.pid\nsocket          = \/var\/run\/mysqld\/mysqld.sock\nport            = 3306\nbasedir         = \/usr\ndatadir         = \/var\/lib\/mysql\ntmpdir          = \/tmp\nlc-messages-dir = \/usr\/share\/mysql\nskip-external-locking\n#\n# Instead of skip-networking the default is now to listen only on\n# localhost which is more compatible and is not less secure.\nbind-address            = 127.0.0.1\n<\/pre>\n\n\n\n
With CentOS and other Red Hats, the primary configuration file is stored at the slightly different location, open it for inspection with<\/p>\n\n\n\n
sudo vi \/etc\/my.cnf<\/pre>\n\n\n\n
[mysqld]\ndatadir=\/var\/lib\/mysql\nsocket=\/var\/lib\/mysql\/mysql.sock<\/pre>\n\n\n\n
The lines here to pay close attention to are \u2018socket\u2019, \u2018datadir\u2019 and \u2018bind-address\u2019. 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 \u2018datadir\u2019 is to use this command below<\/p>\n\n\n\n
sudo ls -l \/var\/lib\/mysql\/<\/pre>\n\n\n\n
The output will list all files in that directory, it should contain at least the following plus any databases you have created.<\/p>\n\n\n\n
drwx------ 2 mysql root      4096 Aug  5 12:23 mysql\ndrwx------ 2 mysql mysql     4096 Aug  5 12:29 performance_schema\n<\/pre>\n\n\n\n
If the data directory or socket has been moved and MySQL doesn\u2019t know where they are, fix the configuration file to point to the correct directories. You can search for the folders with the following command.<\/p>\n\n\n\n
sudo find \/ -name performance_schema  && sudo find \/ -name mysql.sock<\/pre>\n\n\n\n
The third parameter you\u2019ll 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\u2019t 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\u2019s own private IP.<\/p>\n\n\n\n
Check the error logs<\/h2>\n\n\n\n
If the configuration seems correct and the service is running, but your website still doesn\u2019t load as it should, try checking the logs for any hints to as what might be the cause.<\/p>\n\n\n\n
Debian and Ubuntu servers store error logs to \/var\/log\/mysql\/error.log. You can read through the logs with \u2018less\u2019, but this might not be very convenient as the log includes more than just critical errors. Instead, search the logs using \u2018grep\u2019.<\/p>\n\n\n\n
sudo grep -i error \/var\/log\/mysql\/error.log<\/pre>\n\n\n\n
Should you not be able to find anything within the most recent logs, check the archived ones as well. To do this, use \u2018zgrep\u2019 with otherwise the same command as regular \u2018grep\u2019<\/p>\n\n\n\n
sudo zgrep -i error \/var\/log\/mysql\/error.log.1.gz<\/pre>\n\n\n\n
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.<\/p>\n\n\n\n
sudo grep -i error \/var\/log\/mariadb\/mariadb.log<\/pre>\n\n\n\n
Debian systems also report MySQL events to \/var\/log\/syslog, to filter out everything else, use \u2018grep\u2019 with two keywords separated by .* to express \u2018and\u2019 like in the command below.<\/p>\n\n\n\n
sudo grep -i -E 'mysql.*error' \/var\/log\/syslog<\/pre>\n\n\n\n
If you are having difficulties finding anything helpful, try different keywords such as \u2018start\u2019 to see when the service was last restarted, or \u2018failed\u2019 to find any less critical problems that might not be reported as errors.<\/p>\n\n\n\n
Ask for help<\/h2>\n\n\n\n
Optimistically by now your database should be up and running again, but in case you\u2019ve encountered a more persistent error, feel free to ask for help. Contact our support team<\/a> and try to explain the problem to the best of your ability, also include the steps you\u2019ve taken with their results while troubleshooting the issue. This will help the team in helping you with the problem.<\/p>\n","protected":false},"featured_media":0,"comment_status":"open","ping_status":"closed","template":"","community-category":[123,124],"class_list":["post-24480","tutorial","type-tutorial","status-publish","hentry","community-category-troubleshooting","community-category-databases"],"acf":[],"_links":{"self":[{"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/tutorial\/24480","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/tutorial"}],"about":[{"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/types\/tutorial"}],"replies":[{"embeddable":true,"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/comments?post=24480"}],"wp:attachment":[{"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/media?parent=24480"}],"wp:term":[{"taxonomy":"community-category","embeddable":true,"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/community-category?post=24480"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}