Contact
← Terug naar kennisbank HOSTING

Error establishing a database connection — oplossen WordPress

Eén regel op een witte pagina: Error establishing a database connection. Geen menu, geen content, geen wp-admin meer. WordPress kan zonder database niets — geen post laden, geen pagina renderen, geen inlog. Deze gids loopt alle veelvoorkomende oorzaken door in volgorde van waarschijnlijkheid, met concrete diagnose-commando's en fixes per scenario.

16 min lezen · Laatst gecheckt:

Vóór alles: deze fout betekent één ding — PHP probeert verbinding te maken met je MySQL/MariaDB-database, en krijgt geen succesvolle response. Dat is alles wat de error letterlijk zegt. De échte oorzaak is altijd iets dieper en kan in negen verschillende plekken liggen. Hieronder eerst de snelle eerste-hulp, daarna alle oorzaken in volgorde van hoe vaak ik ze tegenkom.

Eerste hulp: zet WP_DEBUG aan om de echte fout te zien

WordPress toont op de frontend de generieke melding "Error establishing a database connection", maar achter de schermen is er meestal een specifieker bericht (bijv. Access denied for user, Unknown database, Too many connections). Activeer WP_DEBUG om dat te zien:

// In wp-config.php — VÓÓR de regel "/* That's all, stop editing! */"
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Refresh je site één keer, daarna zie je de echte fout in /wp-content/debug.log. Open dat bestand via FTP of bestandsbeheer van je hosting-paneel:

tail -50 wp-content/debug.log

De regel die je zoekt begint meestal met WordPress database error of mysqli_real_connect(). Die specifieke melding bepaalt welke oorzaak hieronder van toepassing is.

Oorzaak 1: verkeerde credentials in wp-config.php (~50% van de gevallen)

Veruit de meest voorkomende oorzaak — vooral na een migratie, hosting-wisseling, of als iemand het wachtwoord van de database-gebruiker heeft gewijzigd zonder wp-config.php bij te werken.

Open wp-config.php in de site-root en check deze vier constanten:

// ** Database settings ** //
define('DB_NAME',     'naam_van_database');
define('DB_USER',     'database_gebruiker');
define('DB_PASSWORD', 'wachtwoord');
define('DB_HOST',     'localhost');

Hoe controleer je of deze kloppen? Log in op je hosting-paneel (cPanel, Plesk, DirectAdmin) en ga naar het database-overzicht. Daar zie je de exacte database-naam en gebruiker. Voor het wachtwoord moet je hem opnieuw instellen — ze worden nooit getoond, alleen ingesteld.

Stappenplan: credentials opnieuw zetten

  1. Open hosting-paneel → MySQL Databases (of equivalent)
  2. Kies de database-gebruiker → "Wachtwoord wijzigen"
  3. Genereer een nieuw, sterk wachtwoord en kopieer het
  4. Plak hetzelfde wachtwoord in wp-config.php bij DB_PASSWORD
  5. Sla op via FTP/SFTP/SSH — geen typfouten, geen extra spaties
  6. Refresh je site

Veelgemaakte fout: een speciaal teken in het wachtwoord (zoals &, $, !) wordt door PHP geïnterpreteerd. Zet het wachtwoord daarom altijd tussen enkele aanhalingstekens: 'wachtwoord$met!speciale&tekens', niet dubbele.

Oorzaak 2: DB_HOST is gewijzigd door je hosting-provider

Hostingbedrijven veranderen soms hun infrastructuur. DB_HOST stond op localhost en is plotseling mysql.jouwhost.nl, of localhost:3306 moet ineens localhost:/var/run/mysqld/mysqld.sock zijn. Dit gebeurt vooral bij:

  • Wisselingen tussen MySQL en MariaDB
  • Migraties van shared naar managed hosting
  • Hosting die overstapt naar gescheiden database-servers
  • cPanel-naar-Plesk-overgangen

De juiste waarde voor DB_HOST staat altijd in je hosting-paneel onder MySQL Databases. Vaak ook in een waarschuwingsmail die je hebt gemist. Veelvoorkomende waarden:

// Lokaal op dezelfde server
define('DB_HOST', 'localhost');

// Aparte database-server
define('DB_HOST', 'mysql.hostnet.nl');
define('DB_HOST', 'db.transip.nl');
define('DB_HOST', 'mysql123.savvii.host');

// Met expliciete poort
define('DB_HOST', 'localhost:3306');

// Via Unix-socket (zeldzaam, vooral managed hosts)
define('DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock');

Oorzaak 3: database-server is daadwerkelijk down

Als je credentials kloppen maar het lukt nog steeds niet, is de database-service zelf misschien gestopt. Op shared hosting kan dit gebeuren bij overbelasting, op een eigen VPS na een herstart of out-of-memory crash.

Hoe controleer je of de database draait?

Op shared hosting: ga naar de status-pagina van je hosting-provider (vaak status.hostingbedrijf.nl). Als daar geen storing staat, neem contact op met support — zij hebben monitoring per server.

Op een eigen VPS: log in via SSH en check:

# Status van MySQL/MariaDB
systemctl status mysql
# of:
systemctl status mariadb

# Als hij gestopt is, herstarten:
sudo systemctl start mysql

# Check waarom hij stopte:
sudo journalctl -u mysql --since "1 hour ago" | tail -50

Veelvoorkomende crash-oorzaken op een VPS: out-of-memory door te kleine swap, vol geraakte schijf (df -h om te checken), of MariaDB/MySQL die crasht door een corrupte InnoDB-tabel.

Oorzaak 4: "Too many connections" — max_connections overschreden

Krijg je in je debug.log letterlijk:

WordPress database error: User 'jouwuser' has exceeded the 'max_user_connections' resource (current value: 25)
WordPress database error: Too many connections

Dan probeert WordPress meer gelijktijdige verbindingen te openen dan toegestaan. Op shared hosting is de limiet vaak 15-30 connections per gebruiker. Oorzaken:

  • Plotselinge traffic-piek — bv. nieuwsbrief uitgestuurd, viral artikel, DDoS-poging
  • Slechte plugin die voor elke pageload tien losse queries afvuurt zonder ze te poolen
  • Defecte cron-jobs die parallel draaien en blijven hangen
  • WP-Cron die stapelt bij hoge traffic — elke pageload triggert een nieuwe cron-run

Snelle fix

Eerst: kijk of je een caching-plugin actief hebt (WP Rocket, W3 Total Cache, LiteSpeed Cache). Als die wegvalt of leeg is, raakt elke bezoeker de database direct. Cache leegmaken en opnieuw warm maken.

Op een eigen server kun je de limiet verhogen in my.cnf:

# /etc/mysql/my.cnf of /etc/my.cnf
[mysqld]
max_connections = 200
max_user_connections = 100
wait_timeout = 60

Daarna: sudo systemctl restart mysql. Wel met mate — meer connections kost RAM. Een betere oplossing is de oorzaak van de connection-storm vinden (slechte plugin, missing cache, etc.).

Oorzaak 5: corrupte database-tabellen

Soms kunnen specifieke tabellen corrupt raken — meestal door een server-crash midden in een schrijf-actie, of bij volle schijf. WordPress heeft hier een ingebouwde repair-tool voor.

Voeg deze regel toe aan wp-config.php:

define('WP_ALLOW_REPAIR', true);

Open daarna in je browser:

https://jouwsite.nl/wp-admin/maint/repair.php

Klik op "Repair Database" (alleen repareren) of "Repair and Optimize Database". Wacht tot het klaar is — kan een paar minuten duren bij grote databases.

Belangrijk: verwijder de WP_ALLOW_REPAIR-regel direct na gebruik weer uit wp-config.php. Deze pagina is publiek toegankelijk zonder login — als je hem aan laat staan kan iedereen er aanrollen.

Repair via SSH (krachtiger)

Heb je SSH-toegang en is repair.php niet voldoende, gebruik dan direct mysqlcheck:

mysqlcheck --auto-repair --check --all-databases -u root -p

# Of voor één specifieke database:
mysqlcheck --auto-repair --check jouw_db_naam -u jouw_user -p

Oorzaak 6: database is vol of overschreden

Op shared hosting is er soms een limiet op database-grootte (bv. 1 GB). Als je daar overheen gaat, weigert de server nieuwe writes en kan WordPress geen sessies/transients meer opslaan — wat de connectie effectief stuk maakt.

Check de database-grootte in je hosting-paneel of via SSH:

mysql -u jouw_user -p
SELECT table_schema "Database",
ROUND(SUM(data_length + index_length) / 1024 / 1024, 1) "Size MB"
FROM information_schema.tables
GROUP BY table_schema;

De grootste boosdoeners zijn meestal: wp_options (autoload-rotzooi), wp_postmeta (verzamelde meta van plugins die niet opruimen) en wp_actionscheduler_actions (WooCommerce). Een artikel over het opschonen van wp_options staat in de gids over trage WordPress-sites versnellen.

Oorzaak 7: PHP mist mysqli-extensie

Na een PHP-versie-upgrade kan het gebeuren dat de mysqli-extensie nog niet geactiveerd is op de nieuwe versie. Symptoom: in je error_log zie je:

PHP Fatal error: Uncaught Error: Call to undefined function mysqli_connect()
PHP Warning: Class "mysqli" not found

Test op de server welke extensies actief zijn:

php -m | grep -i mysql

Je zou mysqli en pdo_mysql moeten zien. Zo niet:

  • Shared hosting: ga naar PHP-instellingen in je paneel en activeer de mysqli-extensie. Bij sommige hosts staat dit los per PHP-versie.
  • Eigen server (Ubuntu/Debian): sudo apt install php8.2-mysql (vervang versie). Daarna sudo systemctl restart php8.2-fpm.

Meer over PHP-versies veilig upgraden: PHP versie veilig upgraden.

Oorzaak 8: hosting-account is opgeschort

Gevoelige onderwerp, maar gebeurt: hosting-provider schorst je account vanwege onbetaalde factuur, abuse-melding (bv. spam vanaf je site) of overschrijding van fair-use. Database wordt dan vaak read-only gezet of helemaal afgesloten — frontend toont nog wel HTML uit cache, maar elke nieuwe DB-query faalt.

Check je e-mail (incl. spam-folder) op meldingen van je hosting-provider. Bel ze direct als je dit vermoedt — vaak is het binnen het uur op te lossen na betaling of na opruim-actie.

Oorzaak 9: brute-force / DDoS op wp-login.php

Een aanvalsgolf op /wp-login.php kan in seconden honderden DB-connections opvreten. Symptomen:

  • Site werkt traag of geeft database-errors, vooral op piek-momenten
  • Access-log toont massa POSTs naar wp-login.php vanaf willekeurige IP's
  • xmlrpc.php wordt ook aangevallen

Snelle bescherming via .htaccess:

# Limiteer wp-login.php tot jouw IP
<Files wp-login.php>
    Require ip 1.2.3.4
</Files>

# xmlrpc.php helemaal uit (nodig?)
<Files xmlrpc.php>
    Require all denied
</Files>

Voor langere termijn: een security-plugin (Solid Security, Wordfence) met rate-limiting, of beter — Cloudflare WAF met een Custom Rule die agressieve POSTs naar wp-login blokkeert.

Diagnose-volgorde — wat ik zelf zou doen

Bij een klant die belt met deze error, doorloop ik dit lijstje altijd in deze volgorde:

  1. WP_DEBUG aanzetten en de echte error in debug.log opzoeken (1 min)
  2. Hosting-paneel openen — staat database online? (30 sec)
  3. wp-config.php credentials checken tegen hosting-paneel (1 min)
  4. Vanaf SSH testen: mysql -u USER -p -h HOST DBNAME → werkt verbinding direct? (1 min)
  5. Status-pagina hosting-provider raadplegen (30 sec)
  6. WP_ALLOW_REPAIR draaien als de database wel bereikbaar is maar tabellen mogelijk corrupt (5 min)
  7. access-log analyseren bij verdenking van traffic-piek (5-10 min)
  8. Backup terugzetten als laatste redmiddel — niet eerder, je verliest dan recente data (15-30 min)

Stap 1 t/m 4 lossen ~80% van alle gevallen op. De rest vereist diepere diagnose.

Preventie — voorkomen is beter

Als je site eenmaal weer draait, zorg dat dit niet meer gebeurt:

  • Dagelijkse backups met tooling die ook database-dumps maakt — niet alleen file-backup. UpdraftPlus, BackWPup, of server-side via cPanel/Plesk backup.
  • Uptime-monitoring die je waarschuwt vóór klanten bellen — UptimeRobot is gratis voor 50 monitors.
  • Database-onderhoud: maandelijkse OPTIMIZE TABLE + opschonen oude transients.
  • Cache-laag die de database ontlast bij traffic-pieken (Redis, Memcached, page-cache).
  • WP-config redundant maken: zet credentials in een aparte .env-achtig bestand buiten de webroot, zodat ze niet uitlekken bij een misconfiguratie.
  • Migratie-checklist waarin DB_HOST/DB_NAME/DB_USER/DB_PASSWORD altijd expliciet staan vermeld vóór en na elke verhuizing.

Zelf gerepareerd of zit je vast?

Met dit stappenplan kom je in 80% van de gevallen tot een fix. Maar als je vermoedt dat er iets fundamenteels mis is — corrupte InnoDB-tabellen die niet repareren, hosting die geen support biedt, of je site zit in een crash-loop — schroom niet contact op te nemen. Database-recovery is delicaat: één verkeerde restore en je verliest weken aan data.