Error establishing a database connection in WordPress: oorzaken en oplossingen

Je site laat een witte pagina zien met één zin: Error establishing a database connection. Het dashboard is niet bereikbaar. Formulieren, bestellingen en inloggen falen allemaal op dezelfde manier, want WordPress krijgt simpelweg geen contact met MySQL of MariaDB. In de meeste gevallen vind je de oorzaak en fix je het binnen een kwartier, zonder dat je de database zelf hoeft aan te raken.

Wat deze fout eigenlijk betekent

WordPress bewaart berichten, gebruikers, instellingen en orderdata in een database en haalt die data bij elk request op via de $wpdb class. Zodra PHP geen verbinding kan openen met die database, of de database de verbinding halverwege de handshake dichtgooit, heeft WordPress niets om te renderen. Het stopt en toont deze fout in plaats van een pagina. De oorzaak zit bijna altijd aan de databasekant, niet in PHP of je thema.

Meest voorkomende oorzaken, gesorteerd op waarschijnlijkheid

1. Verkeerde credentials in wp-config.php. Veruit de meest voorkomende oorzaak. Gebeurt meestal na een migratie, een wachtwoordrotatie, of een host die je database stilletjes naar een andere server heeft verplaatst.
2. Database-server is down of onbereikbaar. Een storing bij de host, een gecrasht MySQL-proces op een VPS, of een netwerkprobleem tussen de webserver en de database-server.
3. Too many connections doordat max_connections vol zit. Een verkeerspiek, een doorgeslagen plugin, of een backup-job die sessies open houdt. MySQL documenteert dit als een harde limiet op gelijktijdige clients, standaard 151.
4. Permissies van de database-user ingetrokken of user verwijderd. Komt voor als een controlepaneel de users herbouwt na een factureringswijziging, of als iemand handmatig een oude user opruimt.
5. Corrupte tabellen. Zeldzaam met InnoDB, vaker met oude MyISAM-tabellen of na een harde reboot midden in een write.

Eerst diagnose, dan pas fixen

Voordat je iets wijzigt, bevestig welke van de vijf oorzaken je in handen hebt. Dat kost twee minuten en voorkomt dat je in wp-config.php gaat rommelen terwijl het probleem op de database-server zit.

Maak in de WordPress-root een klein bestandje dbcheck.php met alleen deze inhoud:

<?php
// Gebruikt dezelfde constants als WordPress, dus dit komt exact overeen met wp-config.php.
require __DIR__ . '/wp-config.php';

$link = @mysqli_connect(DB_HOST, DB_USER, DB_PASSWORD, DB_NAME);
if (!$link) {
    echo 'FAIL: ' . mysqli_connect_errno() . ' ' . mysqli_connect_error();
    exit;
}
echo 'OK: connected to ' . DB_NAME . ' on ' . DB_HOST;
mysqli_close($link);

Open het in je browser via https://jouwsite.nl/dbcheck.php en lees het exacte foutnummer en de melding. Gooi dit bestand meteen weg zodra je je antwoord hebt, want het lekt je database-host. De MySQL error reference koppelt het nummer aan een oorzaak:

• 1045 Access denied wijst op verkeerde user of wachtwoord
• 1044 Access denied for user to database wijst op permissies op de database zelf
• 1049 Unknown database wijst op een verkeerde DB_NAME
• 2002 Can't connect to MySQL server of 2005 Unknown MySQL server host wijst op DB_HOST (zie de wp-config.php-instellingenreferentie voor de volledige database-constant tabel) of een dode database-server
• 1040 Too many connections betekent dat max_connections vol zit

Nu weet je naar welke fix hieronder je moet springen.

Fix 1: verkeerde credentials in wp-config.php

Hier begin je als dbcheck.php 1044, 1045 of 1049 teruggaf, of als de site uitviel direct na een migratie, wachtwoordwissel of verhuizing.

Open wp-config.php in de WordPress-root via SFTP of de file manager van je host. Je zoekt vier constants:

define('DB_NAME', 'mijnsite_wp');
define('DB_USER', 'mijnsite_wp');
define('DB_PASSWORD', 'correct-horse-battery-staple');
define('DB_HOST', 'localhost');

Vergelijk elke waarde met de database-sectie in je hostingpanel. Wachtwoorden zijn hoofdlettergevoelig en speciale tekens zijn een vaste bron van ellende, zeker bij auto-gegenereerde wachtwoorden met een ' of $ erin. Voor DB_HOST is het op shared hosting bijna altijd localhost, maar managed en cloud hosts gebruiken vaak een hostname als db-primary.internal of een socket-pad zoals localhost:/var/run/mysqld/mysqld.sock. Bij twijfel is de juiste waarde gewoon wat je hostingpanel naast de database laat zien, niet wat je nog uit je hoofd wist van de oude server.

Sla op, herlaad de front page en draai dbcheck.php opnieuw. Je weet dat het werkte als de voorpagina normaal laadt en dbcheck.php OK: connected teruggeeft.

Fix 2: database-server is down of onbereikbaar

Je zit hier als dbcheck.php 2002 of 2005 gaf, of als de credentials kloppen maar de verbinding gewoon timeout.

Check eerst de statuspagina van je host. Goede hosts communiceren storingen proactief; een lopende incident-melding over "MySQL cluster" of "database server 04" is het snelste antwoord dat je krijgt. Zegt je host niks, log dan in op het hostingpanel en probeer phpMyAdmin of Adminer te openen. Lukt dat ook niet, dan is de database-server zelf down en valt er aan jouw kant niets te fixen. Open een ticket met de exacte foutmelding en de database-host-naam erin.

Draai je je eigen VPS of cloud-server? Ga dan met SSH naar binnen en kijk naar de service:

# systemd op Debian/Ubuntu met MariaDB 10.6
systemctl status mariadb

# of MySQL 8.0
systemctl status mysql

Is de service inactive of failed, check dan eerst je schijfruimte met df -h. Een volle disk is veruit de meest voorkomende reden dat MySQL weigert te starten of midden in een request crasht. Zodra je ruimte vrij hebt, start de service weer en lees de log:

tail -n 50 /var/log/mysql/error.log

Je weet dat het werkte als systemctl status active (running) toont en dbcheck.php OK: connected geeft.

Komt de site wel terug maar valt 'ie binnen een paar minuten weer om, dan zit er een dieper resource-probleem onder. Het artikel over hoog CPU-verbruik op een WordPress-server loopt je door het vinden van het proces dat je bak opvreet.

Fix 3: Too many connections (max_connections is vol)

dbcheck.php geeft 1040 als de database z'n connection pool heeft uitgeput. De MySQL-documentatie beschrijft max_connections als de limiet die MySQL afdwingt op gelijktijdige clients, standaard 151 op MySQL 8.0 en MariaDB 10.6.

Op shared hosting kun je die limiet niet zelf verhogen. Neem contact op met je host met het 1040-nummer en het tijdstip waarop het begon, en vraag of een buurman op dezelfde database-server de pool dichttrekt. Op een VPS of managed server die jij beheert, log je in op MySQL als admin en bevestig je dit:

SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';
SHOW PROCESSLIST;

Zit Threads_connected tegen max_connections aan, scan dan de processlist op langlopende queries. Negen van de tien keer is het een backup-job, een zoekquery van een overambitieuze plugin, of een crawler die steeds dezelfde trage pagina hamert. Sloop de ergste kandidaten met KILL <id> om snel ruimte te maken, en pak daarna de oorzaak aan: caching erbij, minder parallelle backups, of max_connections in my.cnf verhogen als je genoeg RAM hebt om het te dragen. Elke verbinding kost geheugen, dus max_connections verdubbelen op een 2 GB VPS is een goede manier om één storing voor een andere in te ruilen.

Je weet dat het werkte als dbcheck.php OK geeft en SHOW STATUS LIKE 'Threads_connected' ruim onder de limiet blijft tijdens een normale load.

Blijft dit terugkomen, dan ligt het onderliggende probleem meestal bij een traag query-patroon, niet bij een harde limiet. Het artikel over een trage WordPress-database behandelt hoe je de query vindt die die verbindingen vasthoudt.

Fix 4: database-user-permissies ingetrokken

Hier zit je als dbcheck.php 1044 laat zien (toegang tot de database wordt geweigerd ondanks correcte user en wachtwoord), of als de credentials in wp-config.php exact matchen met het panel maar phpMyAdmin-login met dezelfde waarden ook faalt.

In cPanel en Plesk betekent dit meestal dat de user los is gekomen van de database. Ga naar de database-sectie, zoek je database op en koppel de user opnieuw met ALL PRIVILEGES (behalve GRANT OPTION, dat heeft WordPress nooit nodig). Is de user zelf verwijderd, maak dan een nieuwe aan, koppel 'm aan de database en werk DB_USER en DB_PASSWORD in wp-config.php bij. Opslaan, herladen, checken met dbcheck.php.

Je weet dat het werkte als dbcheck.php OK: connected teruggeeft en het WordPress-dashboard laadt.

Fix 5: corrupte tabellen

Corruptie is het laatste wat je checkt, omdat het op moderne WordPress-installaties de minst voorkomende oorzaak is. Je zit hier als dbcheck.php wel verbinding krijgt, maar WordPress de fout alsnog af en toe laat zien, of als het dashboard een aparte melding toont: One or more database tables are unavailable. The database may need to be repaired.

Maak eerst een volledige database-export via de backup-tool van je host of via de Export-functie in phpMyAdmin. Voordat je iets anders doet. Schakel daarna de WordPress-reparatiemodus in met één regel in wp-config.php:

define('WP_ALLOW_REPAIR', true);

Ga naar https://jouwsite.nl/wp-admin/maint/repair.php en draai Repair Database. Haal die regel weg op het moment dat je klaar bent. Zolang 'ie erin staat, is de repair-pagina zonder login bereikbaar, wat een serieuze exposure is.

Belangrijke kanttekening: de repair-pagina draait het MySQL-commando REPAIR TABLE, en dat werkt alleen op MyISAM- en Aria-tabellen. InnoDB is al jaren de default storage engine van WordPress en ondersteunt REPAIR TABLE gewoon niet. Zijn jouw tabellen InnoDB en doet de repair-pagina niets zinnigs, dan is de juiste weg om de kapotte tabel te dumpen, te droppen en opnieuw te importeren vanuit een backup. Op een gezonde server lost InnoDB z'n eigen crash recovery de meeste problemen automatisch op bij startup, dus corruptie die zo erg is dat 'ie een restart overleeft betekent eigenlijk altijd: terugzetten uit backup.

Je weet dat het werkte als de dashboard-melding weg is en de site normaal laadt bij een volledige test over voorpagina, een productpagina en een login.

Wanneer je hulp moet inschakelen

Krijg je het met geen van bovenstaande fixes opgelost? Stop dan met prutsen in de database en open een ticket bij je host of bij mij. Verzamel eerst dit rijtje, zodat de eerste reactie je ook echt verder helpt:

• De exacte foutmelding (wat er op de voorkant staat en een eventuele admin-melding)
• Het exacte foutnummer uit dbcheck.php (bijvoorbeeld 1045 of 2002)
• Je WordPress-, PHP- en MySQL- of MariaDB-versies
• Je hosting-tier (shared, VPS, managed, cloud)
• De waarde van DB_HOST uit wp-config.php
• Elke wijziging aan de site in de afgelopen 48 uur: migraties, plugin-updates, wachtwoordrotaties, backup-jobs
• De laatste 50 regels van /var/log/mysql/error.log of het equivalent in je hostingpanel

Dat rijtje is het verschil tussen een support-engineer die gokt en een support-engineer die het in één reply fixt.

Een databasefout die alleen in /wp-admin opduikt en niet op de voorkant, kan ook als de kritieke fout op deze website-melding naar boven komen, omdat WordPress de fatal opvangt en de specifieke oorzaak achter die generieke melding verbergt. Zie je ze allebei, behandel de databasefout dan als de root cause. Datzelfde geldt voor transactionele mail die ineens niet meer verstuurd wordt, want WordPress bewaart mail-queues en instellingen in de database en kan niks versturen zolang die verbinding eruit ligt.

Voorkomen dat het terugkomt

• Automatiseer dagelijkse database-backups en test een restore elk kwartaal. Een backup die je nooit hebt teruggezet is een hoop, geen backup.
• Cache agressief, zodat verkeerspieken niet eens tot de database komen. Paginacaching verandert 100 requests in één query.
• Monitor het aantal database-verbindingen en de 1040-fout, niet alleen uptime. Een goede monitor waarschuwt je bij 70% van max_connections zodat je kunt ingrijpen voordat de site omvalt.
• Op shared hosting: vraag je host wat hun max_connections is en of ze luidruchtige buren afknijpen. Kunnen ze beide vragen niet beantwoorden, dan zegt dat wat over je tier.
• Rouleer database-wachtwoorden bewust, met een kort lijstje waar "wp-config.php bijwerken" ook op staat. De meeste "verrassingsstoringen" met credentials zijn self-inflicted en vergeten.