{"id":5065,"date":"2026-08-30T17:58:33","date_gmt":"2026-08-30T14:58:33","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/?p=5065"},"modified":"2026-08-30T17:46:45","modified_gmt":"2026-08-30T14:46:45","slug":"wordpress-database-connection-error-fixes","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/wordpress-database-connection-error-fixes\/","title":{"rendered":"WordPress Error Establishing a Database Connection: Fixes"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_WordPress_shows_a_database_connection_error\"><span class=\"toc_number toc_depth_1\">1.<\/span> Why WordPress shows a database connection error<\/a><\/li><li><a href=\"#Start_with_the_first_few_minutes\"><span class=\"toc_number toc_depth_1\">2.<\/span> Start with the first few minutes<\/a><\/li><li><a href=\"#1_Verify_wp-configphp_without_exposing_secrets\"><span class=\"toc_number toc_depth_1\">3.<\/span> 1. Verify wp-config.php without exposing secrets<\/a><\/li><li><a href=\"#2_Find_out_whether_MariaDB_is_running\"><span class=\"toc_number toc_depth_1\">4.<\/span> 2. Find out whether MariaDB is running<\/a><\/li><li><a href=\"#3_Check_DB_HOST_and_the_connection_socket\"><span class=\"toc_number toc_depth_1\">5.<\/span> 3. Check DB_HOST and the connection socket<\/a><\/li><li><a href=\"#4_Check_the_tables_before_attempting_repairs\"><span class=\"toc_number toc_depth_1\">6.<\/span> 4. Check the tables before attempting repairs<\/a><\/li><li><a href=\"#5_Separate_plugin_failures_from_connection_failures\"><span class=\"toc_number toc_depth_1\">7.<\/span> 5. Separate plugin failures from connection failures<\/a><\/li><li><a href=\"#Use_the_symptom_to_choose_the_first_check\"><span class=\"toc_number toc_depth_1\">8.<\/span> Use the symptom to choose the first check<\/a><\/li><li><a href=\"#Give_support_evidence_not_just_the_error_message\"><span class=\"toc_number toc_depth_1\">9.<\/span> Give support evidence, not just the error message<\/a><\/li><li><a href=\"#Reduce_the_chance_of_another_outage\"><span class=\"toc_number toc_depth_1\">10.<\/span> Reduce the chance of another outage<\/a><\/li><li><a href=\"#Frequently_asked_questions\"><span class=\"toc_number toc_depth_1\">11.<\/span> Frequently asked questions<\/a><ul><li><a href=\"#Can_hosting_cause_a_WordPress_database_connection_error\"><span class=\"toc_number toc_depth_2\">11.1.<\/span> Can hosting cause a WordPress database connection error?<\/a><\/li><li><a href=\"#Which_lines_in_wp-configphp_should_I_check\"><span class=\"toc_number toc_depth_2\">11.2.<\/span> Which lines in wp-config.php should I check?<\/a><\/li><li><a href=\"#Is_repairphp_safe_to_use\"><span class=\"toc_number toc_depth_2\">11.3.<\/span> Is repair.php safe to use?<\/a><\/li><li><a href=\"#What_should_I_check_when_the_error_is_intermittent\"><span class=\"toc_number toc_depth_2\">11.4.<\/span> What should I check when the error is intermittent?<\/a><\/li><\/ul><\/li><\/ul><\/div>\n<h2><span id=\"Why_WordPress_shows_a_database_connection_error\">Why WordPress shows a database connection error<\/span><\/h2>\n<p>Few things make a site owner sit up faster than seeing <em>&#8220;Error establishing a database connection&#8221;<\/em> at midnight. Visitors cannot load the site, <code>\/wp-admin\/<\/code> is unavailable, and the message rarely identifies the failed layer. The web server may be healthy. MariaDB or MySQL may be stopped, the credentials may be wrong, the disk may be full, a table may be damaged, or the account may have reached a resource limit.<\/p>\n<p>In support tickets, I often see the same first reaction: someone starts changing random lines in <code>wp-config.php<\/code>. That sometimes reaches the cause. It can also turn one problem into two. I begin by finding out whether the whole site is down or only one page, plugin, or administrative function is affected. Then I compare the web server, PHP, and database logs for the same time window.<\/p>\n<p>Let me put it this way: one WordPress message can represent several unrelated failures. I work from low-risk observations toward changes that affect the site. Before repairing tables or editing configuration files, I make sure there is a usable backup.<\/p>\n<h2><span id=\"Start_with_the_first_few_minutes\">Start with the first few minutes<\/span><\/h2>\n<p>First, establish the scope. Open the site in a private window, try another network, and check <code>\/wp-admin\/<\/code>. If only a custom page used by one plugin fails, you may be looking at a slow or broken query rather than a database connection failure.<\/p>\n<p>If you have SSH access, I start with these checks:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">df -h\nfree -m\nsystemctl status mariadb --no-pager\nsystemctl status mysql --no-pager<\/code><\/pre>\n<p><code>df -h<\/code> shows filesystem usage, while <code>free -m<\/code> gives a quick view of memory. The last two commands check the service names commonly used on Linux systems. Depending on the distribution, the database service may be called <code>mysql<\/code> or <code>mariadb<\/code>. Do not restart both blindly. Read first.<\/p>\n<p>I once handled a &#8220;site is down&#8221; ticket where access-log rotation had been forgotten. The root filesystem was at 100 percent, and the database failure we suspected was really a storage problem. Since then, disk usage has been one of my first checks, before I touch credentials or tables.<\/p>\n<p>Use the same caution with commands copied from the internet. I do not begin diagnosis with a <code>curl | sudo bash<\/code> installer, and neither should you. Understand a command before giving it root access.<\/p>\n<h2><span id=\"1_Verify_wp-configphp_without_exposing_secrets\">1. Verify <code>wp-config.php<\/code> without exposing secrets<\/span><\/h2>\n<p>WordPress normally reads its database settings from <code>wp-config.php<\/code> in the document root. I check these values:<\/p>\n<ul>\n<li><code>DB_NAME<\/code>: the database name<\/li>\n<li><code>DB_USER<\/code>: the database username<\/li>\n<li><code>DB_PASSWORD<\/code>: the user&#8217;s password<\/li>\n<li><code>DB_HOST<\/code>: the database hostname, address, or socket<\/li>\n<li><code>$table_prefix<\/code>: the table prefix used by WordPress<\/li>\n<\/ul>\n<p>A common post-migration mistake is importing the database while leaving <code>DB_NAME<\/code> or <code>DB_USER<\/code> set to the old account. Generating a new database password in a hosting panel and forgetting to update <code>wp-config.php<\/code> produces the same symptom.<\/p>\n<p>Never paste the password into a support ticket, screenshot, or shared chat. To inspect the non-secret settings on the server, I use:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">cd \/home\/username\/public_html\ngrep -E &quot;DB_NAME|DB_USER|DB_HOST|table_prefix&quot; wp-config.php<\/code><\/pre>\n<p>This prints the basic settings without displaying the password. Compare the database name with the value in your hosting panel. cPanel and CyberPanel may add the account username to database and user names, so the correct value could be <code>username_site_wp<\/code>, not simply <code>site_wp<\/code>.<\/p>\n<p>Test the credentials directly with the MySQL client instead of testing only through WordPress:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">mysql -h 127.0.0.1 -u database_user -p database_name<\/code><\/pre>\n<p>Enter the password when prompted. A message such as <code>Welcome to the MariaDB monitor<\/code> shows that the credentials and network path work for that test. <code>Access denied<\/code> points to the username, password, or grants. Do not put the password directly in the command; it can remain in shell history.<\/p>\n<h2><span id=\"2_Find_out_whether_MariaDB_is_running\">2. Find out whether MariaDB is running<\/span><\/h2>\n<p>Correct credentials cannot help if the database service has stopped. Memory exhaustion, maintenance, and storage errors can all cause that. I check the service and its recent logs together:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo systemctl status mariadb --no-pager\nsudo journalctl -u mariadb -n 80 --no-pager<\/code><\/pre>\n<p>Look for messages such as <code>InnoDB: Unable to lock<\/code>, <code>Too many connections<\/code>, <code>Out of memory<\/code>, and disk-write errors. <code>systemctl status<\/code> tells you whether the service is running; <code>journalctl<\/code> often explains why it stopped.<\/p>\n<p>A full filesystem can prevent MariaDB from creating temporary files or binary logs. Use <code>df -h<\/code> to identify the full mount point, then inspect large directories with <code>ncdu<\/code>. Fix log rotation or the underlying storage problem. Do not delete random files, especially anything under <code>\/var\/lib\/mysql<\/code>. That can turn a recoverable outage into data loss.<\/p>\n<p>If the service is stopped and the logs do not show a configuration error, a restart may be appropriate:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo systemctl restart mariadb\nsudo systemctl status mariadb --no-pager<\/code><\/pre>\n<p>A restart can restore access briefly, but the error will return if memory, disk, or connection pressure remains. On shared hosting, you will not have permission to restart MariaDB. Ask the provider to check the service state, disk usage, and database logs for the affected period.<\/p>\n<h2><span id=\"3_Check_DB_HOST_and_the_connection_socket\">3. Check <code>DB_HOST<\/code> and the connection socket<\/span><\/h2>\n<p>On many Linux servers, <code>DB_HOST<\/code> set to <code>localhost<\/code> makes the client use a Unix socket instead of TCP. The connection fails if MariaDB uses a different socket path or if the provider keeps the database on another server.<\/p>\n<p>For a local database, I may test the loopback address:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">define( &#039;DB_HOST&#039;, &#039;127.0.0.1&#039; );<\/code><\/pre>\n<p><code>localhost<\/code> and <code>127.0.0.1<\/code> are not always equivalent. The first can direct the client to a Unix socket; the second requests a TCP connection. Back up the file first, and check the PHP syntax after editing it.<\/p>\n<p>If the database is remote, use the hostname supplied by the provider. The remote firewall must allow the source IP, MariaDB must listen on an appropriate address, and the database user must have a grant for the correct host. <code>user@localhost<\/code> and <code>user@10.0.0.%<\/code> are different grants.<\/p>\n<p>For a non-standard port, WordPress accepts this format:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">define( &#039;DB_HOST&#039;, &#039;db.internal.example:3307&#039; );<\/code><\/pre>\n<p>After changing the setting, verify the destination and port. Two services can belong to the same project without running on the same machine. Confirm the hostname and port with the hosting provider.<\/p>\n<h2><span id=\"4_Check_the_tables_before_attempting_repairs\">4. Check the tables before attempting repairs<\/span><\/h2>\n<p>If the service is running and the credentials work but only some pages fail, a damaged table is one possibility. Power loss, a full disk, faulty storage, or an interrupted write can cause it.<\/p>\n<p>Start with a database export. With SSH access and WP-CLI installed, I would run:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">cd \/home\/username\/public_html\nwp db export \/home\/username\/backup-$(date +%F-%H%M).sql<\/code><\/pre>\n<p>This writes the WordPress database to a timestamped SQL file. Confirm that the file exists, has a sensible size, and is copied to separate storage. One copy on the same disk is not protection against disk failure.<\/p>\n<p>Then check the tables:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">wp db check<\/code><\/pre>\n<p>If the command reports no errors, corruption becomes less likely. If it identifies damaged tables, ask your hosting provider or database administrator for the appropriate recovery procedure. InnoDB recovery is not the same as running the simple <code>REPAIR TABLE<\/code> command often associated with MyISAM.<\/p>\n<p>WordPress also has a built-in repair screen. Add this temporarily to <code>wp-config.php<\/code>:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">define( &#039;WP_ALLOW_REPAIR&#039;, true );<\/code><\/pre>\n<p>Then open <code>https:\/\/example.com\/wp-admin\/maint\/repair.php<\/code>. Remove the line immediately afterward. The page does not require a login, so leaving it enabled creates an avoidable security risk. Start with the check-only option, and do not run repairs without a valid backup and a clear understanding of the damage.<\/p>\n<p>If a WordPress update was interrupted, a <code>.maintenance<\/code> file may remain in the document root. That normally leaves a maintenance screen rather than producing a database connection error. If the message is <em>Error establishing&#8230;<\/em>, deleting <code>.maintenance<\/code> will not fix it.<\/p>\n<h2><span id=\"5_Separate_plugin_failures_from_connection_failures\">5. Separate plugin failures from connection failures<\/span><\/h2>\n<p>A database can accept connections while a plugin opens too many connections, runs expensive queries, or causes PHP workers to time out. To a visitor, that may still resemble the familiar WordPress error screen.<\/p>\n<p>If the administration area is unavailable, temporarily rename the plugin directory:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">cd \/home\/username\/public_html\/wp-content\nmv plugins plugins.off<\/code><\/pre>\n<p>If the site recovers, rename the directory back and activate the plugins one at a time. This does not delete plugin files; it only prevents WordPress from finding the directory for the moment.<\/p>\n<p>WP-CLI gives me a more deliberate option:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">wp plugin deactivate --all\nwp plugin list --status=active<\/code><\/pre>\n<p>The first command disables active plugins, while the second shows the current state. On a production site, disabling everything removes important functionality temporarily. On a WooCommerce store, test the cart, checkout, payments, and order administration separately.<\/p>\n<p>Check PHP and WordPress logs too. Leaving <code>WP_DEBUG<\/code> enabled in production can expose sensitive information to visitors. For temporary diagnosis, log errors without displaying them:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">define( &#039;WP_DEBUG&#039;, true );\ndefine( &#039;WP_DEBUG_LOG&#039;, true );\ndefine( &#039;WP_DEBUG_DISPLAY&#039;, false );<\/code><\/pre>\n<p>Inspect <code>wp-content\/debug.log<\/code>, then disable debugging when finished. A repeated reference to one plugin file does not prove that MariaDB is healthy; the plugin may be exhausting connection slots or query resources.<\/p>\n<h2><span id=\"Use_the_symptom_to_choose_the_first_check\">Use the symptom to choose the first check<\/span><\/h2>\n<table>\n<thead>\n<tr>\n<th>Symptom<\/th>\n<th>Likely cause<\/th>\n<th>First check<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>The site and <code>wp-admin<\/code> both fail<\/td>\n<td>Stopped service, incorrect credentials, or full disk<\/td>\n<td><code>df -h<\/code>, service status, and <code>wp-config.php<\/code><\/td>\n<\/tr>\n<tr>\n<td>Only some pages fail<\/td>\n<td>Damaged table, plugin, or heavy query<\/td>\n<td><code>wp db check<\/code> and plugin isolation<\/td>\n<\/tr>\n<tr>\n<td>The error started after a migration<\/td>\n<td>Changed database name, user grant, or <code>DB_HOST<\/code><\/td>\n<td>Direct MySQL connection from the new server<\/td>\n<\/tr>\n<tr>\n<td>The error is intermittent<\/td>\n<td>Resource pressure, connection limit, network issue, or query load<\/td>\n<td>MariaDB logs, PHP-FPM logs, and process usage<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>This table does not diagnose the fault. It helps me choose the first useful check. With intermittent failures, one successful connection test can be misleading. If <code>Too many connections<\/code> appears during busy periods, find the query or plugin consuming connections before increasing the limit.<\/p>\n<h2><span id=\"Give_support_evidence_not_just_the_error_message\">Give support evidence, not just the error message<\/span><\/h2>\n<p>&#8220;My site is down&#8221; gives both sides very little to work with. Include when the error began, the affected domain, whether the outage is continuous or intermittent, the last change you made, and the exact message shown.<\/p>\n<ul>\n<li>Do not send <code>wp-config.php<\/code>; never share passwords or security keys.<\/li>\n<li>Write the time zone clearly, such as \u0130stanbul time if that is where you are working.<\/li>\n<li>Mention the last plugin, theme, PHP, or server change.<\/li>\n<li>Attach the error screen and relevant log lines after masking sensitive data.<\/li>\n<li>If the site uses WooCommerce, say separately whether checkout, orders, and the administration area are affected.<\/li>\n<\/ul>\n<p>Your hosting provider can inspect service logs, disk quotas, MySQL processes, and account limits. Clear symptoms replace the vague argument about whether it is &#8220;the server or the site&#8221; with evidence.<\/p>\n<h2><span id=\"Reduce_the_chance_of_another_outage\">Reduce the chance of another outage<\/span><\/h2>\n<p>Before a WordPress update, I now run <code>wp db export<\/code> almost automatically. In my Proxmox lab at home, an update is allowed to fail on a test VM before it gets anywhere near a customer server. I also test restores. Once a month, I restore a random SQL backup and several WordPress files because a backup that cannot be restored is only a comforting filename.<\/p>\n<p>Monitor disk usage, the MariaDB service, and your certificate-renewal cron job. My Raspberry Pi runs Uptime Kuma for exactly this reason: an unmonitored cron job can quietly stop working. On shared hosting, check panel alerts and resource-usage graphs regularly.<\/p>\n<p>Keep WordPress core, themes, and plugins updated, but do not update blindly without a backup and a way to verify the result. Do not use <code>admin<\/code> as the administrator username or choose a predictable password. For the security checks I use around hosting accounts, see <strong><a href=\"https:\/\/www.dchost.com\/blog\/kucuk-isletmeler-icin-web-hosting-guvenlik-kontrol-listesi\/\">Web Hosting Security Checklist for Small Businesses<\/a><\/strong>.<\/p>\n<p>After a database error, changing permissions to <code>chmod 777<\/code> is not a fix. It changes the name of the problem, not the problem itself. Record the current ownership and permissions, then correct them so the web-server user can access only what it needs.<\/p>\n<p>For a domain or server move, include DNS in the change plan. <strong><a href=\"https:\/\/www.dchost.com\/blog\/dns-kayit-turleri-nedir-a-aaaa-mx-cname-txt-srv-ve-caa-icin-uygulamali-rehber\/\">DNS Record Types Explained: Practical Guide to A, AAAA, MX, CNAME, TXT, SRV and CAA<\/a><\/strong> covers A records, TTL, and verification steps. Your database may be healthy while visitors are still reaching the old server, so a correct fix may not appear everywhere immediately.<\/p>\n<h2><span id=\"Frequently_asked_questions\">Frequently asked questions<\/span><\/h2>\n<h3><span id=\"Can_hosting_cause_a_WordPress_database_connection_error\">Can hosting cause a WordPress database connection error?<\/span><\/h3>\n<p>Yes. A stopped MariaDB service, exhausted disk space, account resource limits, or network access problems can all cause it. If other sites on the same server are affected, service and resource checks on the hosting side should come first.<\/p>\n<h3><span id=\"Which_lines_in_wp-configphp_should_I_check\">Which lines in <code>wp-config.php<\/code> should I check?<\/span><\/h3>\n<p>Check <code>DB_NAME<\/code>, <code>DB_USER<\/code>, <code>DB_PASSWORD<\/code>, and <code>DB_HOST<\/code>. Also confirm that the database user can access that database. Seeing the expected text in the file is not enough; the credentials must work from the relevant host.<\/p>\n<h3><span id=\"Is_repairphp_safe_to_use\">Is <code>repair.php<\/code> safe to use?<\/span><\/h3>\n<p>Take a working database backup first, and remove the <code>WP_ALLOW_REPAIR<\/code> line immediately afterward. The page is accessible without authentication, so leaving it enabled is a security risk. For InnoDB problems, choose the recovery method carefully instead of assuming that a simple repair command applies.<\/p>\n<h3><span id=\"What_should_I_check_when_the_error_is_intermittent\">What should I check when the error is intermittent?<\/span><\/h3>\n<p>Search MariaDB logs for connection-limit, memory, and timeout messages. PHP-FPM processes, expensive plugin queries, sudden traffic, and storage latency can all cause intermittent failures. Changing only <code>DB_HOST<\/code> will not solve every case.<\/p>\n<p>When I see this error, I start with the layers rather than the screen: disk, service, credentials, connection address, and queries. I save the output after each check. That small habit turns a midnight panic into an incident I can actually follow.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>A practical way to diagnose and fix a WordPress database connection error, from disk and MariaDB checks to wp-config.php, table repairs, plugins, and backups.<\/p>\n","protected":false},"author":4,"featured_media":5062,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[183],"tags":[403,400,399,116,404,402,401],"class_list":["post-5065","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-database-connection-error","tag-mariadb","tag-mysql","tag-wordpress","tag-wordpress-troubleshooting","tag-wp-cli","tag-wp-config-php"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5065","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=5065"}],"version-history":[{"count":1,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5065\/revisions"}],"predecessor-version":[{"id":5067,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5065\/revisions\/5067"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/5062"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=5065"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=5065"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=5065"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}