Plesk Cannot Connect to MySQL Database: How to Fix It

A MySQL connection error in Plesk — typically displayed as “Error establishing a database connection” (in WordPress) or a similar message — means either the database service is down, the credentials stored in the application config are wrong, or the database user does not have the correct permissions. This guide covers each cause in order of likelihood, so you can work through them systematically and restore connectivity as quickly as possible.

Step 1: Confirm MySQL Is Running

The first thing to rule out is whether the MySQL or MariaDB service is actually running. Many connection errors have no other cause.

In Plesk, navigate to Tools & Settings > Services Management and locate MySQL / MariaDB in the list. If the status shows as stopped, click Start. The page will refresh and confirm whether the service came back up.

If you have SSH access to the server, you can check and control the service directly:

1. Connect to the server over SSH as a user with sudo privileges.
2. Check the service status:
   
   systemctl status mariadb
   
   On some systems the service is named mysqld rather than mariadb — try both if the first returns an error.
3. If the service is inactive, attempt to start it:
   
   sudo systemctl start mariadb
4. If it fails to start, check the error log immediately:
   
   sudo tail -n 50 /var/log/mysqld.log
   
   or
   
   sudo tail -n 50 /var/log/mysql/error.log
   
   The log will tell you exactly why the service could not start — common reasons include InnoDB corruption, a full disk, or a socket file conflict.

Step 2: Verify Database Credentials

If MySQL is running but the application still cannot connect, the credentials in your application’s configuration file are the next thing to check. A password reset in Plesk that was not reflected in the config file is a very common cause of this error.

For WordPress sites hosted in Plesk, the credentials are stored in wp-config.php, located in the site’s httpdocs folder. The relevant lines are:

• DB_NAME — the name of the database
• DB_USER — the database username
• DB_PASSWORD — the database password
• DB_HOST — almost always localhost on Plesk shared hosting

To verify the correct values, go to Plesk > Databases, select the relevant database, and click Users. The username will be listed there. If you are unsure whether the password matches what is in wp-config.php, reset it from this screen: click the username, enter a new password, and save. Then open wp-config.php via the Plesk File Manager or over SSH and update the DB_PASSWORD value to match.

1. In Plesk, go to Websites & Domains > [your domain] > Files.
2. Open httpdocs/wp-config.php in the editor.
3. Locate the DB_PASSWORD line and replace the value with the password you just set in Plesk.
4. Save the file and reload the site to test.

Step 3: Check the Database User Has the Correct Permissions

Even with correct credentials, the database user may not have sufficient permissions to read or write to the database — particularly after a migration or if the user was recreated manually.

1. In Plesk, go to Databases and select the relevant database.
2. Click Users, then click the username to open its settings.
3. Confirm that the user has full access to the database. At a minimum, a WordPress installation requires SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, and ALTER privileges.
4. If any privileges are missing, tick Grant all privileges and save.

Step 4: Check if MySQL Is Listening on the Expected Host

If DB_HOST in your config file has been set to something other than localhost — for example a remote IP address — MySQL must be configured to accept remote connections, and the server firewall must allow inbound traffic on port 3306.

For the vast majority of Plesk setups, DB_HOST should be localhost. If it has been changed and you are not running a dedicated remote database server, change it back. To verify whether MySQL is accepting connections on a specific interface:

1. SSH into the server.
2. Run: sudo ss -tlnp | grep 3306
3. If the output shows 127.0.0.1:3306, MySQL is only listening locally — remote connections will fail. If you need remote access, this requires editing the MySQL bind-address setting, which should only be done with firewall rules in place.
4. For most cases, simply ensure DB_HOST is set to localhost in your application config and move on.

Step 5: MySQL Has Crashed or Run Out of Disk Space

If MySQL stops repeatedly rather than staying down consistently, a full disk or InnoDB table corruption is frequently responsible.

1. Check available disk space: df -h
2. If any partition — particularly /var — is at or near 100%, free up space before attempting to restart MySQL. The database cannot write logs or temporary files on a full disk and will crash immediately.
3. Check the error log for InnoDB messages: sudo grep -i "innodb" /var/log/mysqld.log | tail -n 20
4. In Plesk, you can also check disk usage at a glance under Tools & Settings > Server Health.

If InnoDB corruption is present, the repair process depends on the severity. In most cases, running mysqlcheck is the first step: sudo mysqlcheck -u root -p --all-databases --auto-repair. For severe corruption, a restore from backup may be necessary.

Step 6: Too Many Connections

If the MySQL error log or the application error message shows “Too many connections”, the server has reached its max_connections limit and is refusing new connection requests. This typically happens under high traffic or when an application is not closing database connections properly.

1. In Plesk, go to Tools & Settings > Database Servers.
2. Click the database server name to open its settings.
3. Locate the max_connections setting and increase it — a value of 150 to 300 is reasonable for most shared hosting environments.
4. Save the changes. MySQL does not require a full restart to apply this setting when changed through Plesk.
5. As a temporary measure, you can also flush stale connections via phpMyAdmin by running the SQL command: FLUSH HOSTS;

Accessing the Database via phpMyAdmin in Plesk

When troubleshooting a connection error, it is worth verifying that the database itself is intact and accessible independently of your application. Plesk’s built-in phpMyAdmin access bypasses the application credentials entirely and connects using server-level authentication.

1. In Plesk, go to Databases and locate the database in question.
2. Click the phpMyAdmin button to the right of the database name.
3. Once inside, confirm that the database exists in the left-hand panel and that the expected tables are present (for WordPress, you should see tables such as wp_posts, wp_options, and so on).
4. Try running a simple query to confirm the database is readable: SELECT COUNT(*) FROM wp_options;

If phpMyAdmin connects successfully and the tables are intact, the problem lies in the application’s credentials or config file, not the database itself. If phpMyAdmin cannot connect, the issue is at the MySQL service level and the steps in Step 1 and Step 5 should be revisited. Being able to isolate which layer the failure sits in will save significant time when working through a support escalation or contacting a hosting provider.

Related articles: Plesk Troubleshooting Guide