„Fehler beim Aufbau einer Datenbankverbindung“ in WordPress beheben

Kommt der Fehler und geht wieder, oder bleibt er?

Die englische Fassung derselben Meldung lautet „Error establishing a database connection“. Bevor du irgendwo etwas änderst, lade die Seite ein paar Mal neu und beobachte:

• Der Fehler bleibt dauerhaft: Das spricht für falsche Zugangsdaten oder einen ausgefallenen Datenbankserver. Weiter mit Schritt 1 und 2.
• Der Fehler kommt und geht: Das spricht eher für zu viele gleichzeitige Verbindungen, etwa bei viel Besuch oder vielen Bots. Weiter mit Schritt 3.

Das offizielle WordPress-Handbuch Common WordPress errors nennt als häufigste Ursache einen Fehler in der wp-config.php. Wenn sich an der Datei aber niemand zu schaffen gemacht hat, fang trotzdem beim Hoster an. Das geht schneller.

1. Hat der Hoster eine Störung?

Schau auf die Statusseite deines Hosters oder in dessen Störungsmeldungen. Dasselbe WordPress-Handbuch nennt zwei Ursachen auf Hoster-Seite: Der Datenbankserver ist ausgefallen, oder die Datenbank hat ihr Kontingent erreicht und wurde abgeschaltet. Beides kannst du nicht selbst beheben. Ein kurzer Anruf oder ein Ticket beim Hoster spart dir dann die Stunde, die du sonst in der Konfiguration suchst.

Ein schneller Test: Melde dich im Kundenmenü des Hosters bei phpMyAdmin an. Geht das nicht oder lädt es endlos, liegt das Problem sehr wahrscheinlich beim Datenbankserver.

2. Die Zugangsdaten in der wp-config.php prüfen

WordPress liest die Verbindung zur Datenbank aus vier Einträgen in der wp-config.php im Hauptverzeichnis. Öffne die Datei per SFTP und vergleiche sie Zeichen für Zeichen mit den Angaben im Kundenmenü des Hosters:

• DB_NAME: der Name der Datenbank
• DB_USER: der Datenbank-Benutzer
• DB_PASSWORD: sein Passwort
• DB_HOST: der Datenbankserver. Das ist oft localhost, bei vielen Hostern aber ein eigener Servername. Laut WordPress-Doku kann auch eine Portnummer oder ein Socket-Pfad nötig sein.

Typische Auslöser sind ein Passwort, das jemand beim Hoster geändert hat, und ein Umzug auf einen neuen Server, bei dem die alte wp-config.php mitgekommen ist. Wenn du dich mit genau diesen vier Angaben bei phpMyAdmin anmelden kannst, stimmen sie.

3. Zu viele Verbindungen

Kommt der Fehler nur zeitweise, ist die Datenbank oft einfach voll belegt. Die MySQL-Dokumentation erklärt den Fehler „Too many connections“ so: Alle verfügbaren Verbindungen sind von anderen Clients belegt. Wie viele erlaubt sind, regelt die Server-Variable max_connections.

Auf Shared Hosting legt der Hoster diese Grenze fest, und du kannst sie nicht selbst anheben. Was du tun kannst: einen Seiten-Cache einsetzen, damit nicht jeder Aufruf die Datenbank braucht, auffällige Bots sperren und langsame Plugins finden, die Verbindungen lange offen halten. Reicht das nicht, ist ein größerer Tarif die ehrliche Antwort.

4. Beschädigte Tabellen: erst Backup, dann reparieren

Stimmen Server und Zugangsdaten, kann eine beschädigte Tabelle die Ursache sein. WordPress hat dafür ein eigenes Reparatur-Werkzeug. Du schaltest es mit dieser Zeile in der wp-config.php ein:

define( 'WP_ALLOW_REPAIR', true );

Danach rufst du /wp-admin/maint/repair.php auf deiner Domain auf. Zwei Dinge musst du dabei wissen:

1. Die Reparaturseite funktioniert ohne Login. Laut WordPress-Handbuch ist das Absicht, weil man sich bei kaputter Datenbank oft nicht einloggen kann. Genau deshalb muss die Zeile sofort nach der Reparatur wieder raus, sonst kann jeder die Seite aufrufen.
2. Das Werkzeug repariert nicht jede Tabelle. Die MySQL-Dokumentation schreibt, dass sich InnoDB-Tabellen zwar prüfen, aber nicht mit REPAIR TABLE reparieren lassen. Viele WordPress-Datenbanken nutzen heute InnoDB. Welche Engine deine Tabellen haben, zeigt phpMyAdmin in der Tabellenübersicht.

Und vorher kommt ein Backup der Datenbank. Dieselbe MySQL-Dokumentation empfiehlt, vor jeder Reparatur eine Sicherung der Tabelle anzulegen, weil die Reparatur unter Umständen Daten kosten kann. So arbeiten wir auch im Notfall: Bevor wir am Server etwas verändern, exportieren wir die komplette Datenbank und sichern das wp-content-Verzeichnis.

Das Fehlerprotokoll statt Raten

Hilft keiner der vier Schritte, sag WordPress, was es protokollieren soll. Laut Handbuch zeigt WordPress Datenbankfehler nur an, wenn WP_DEBUG auf true steht. Schreib sie mit WP_DEBUG_LOG in eine Datei statt auf den Bildschirm, damit Besucher nichts davon sehen, und schalte beides wieder ab, sobald du die Ursache kennst. Die Debug-Anleitung rät ausdrücklich davon ab, die Debug-Werkzeuge dauerhaft auf einer Live-Seite laufen zu lassen.

Und wenn es ein Hack ist?

Das WordPress-Handbuch nennt auch diese Möglichkeit: Stimmt die wp-config.php und hat der Hoster keine Störung, kann die Seite gehackt worden sein. Ein Hinweis darauf ist eine wp-config.php, die sich verändert hat, ohne dass jemand von euch daran war. Dann reparierst du nicht weiter an der Datenbank herum, sondern gehst vor wie in unserem Ratgeber WordPress gehackt: Was jetzt zu tun ist.

Wann du aufhören solltest

Hol dir Hilfe, statt weiterzuprobieren, wenn:

• ein Shop offline ist und jede Stunde Bestellungen kostet,
• es kein aktuelles Backup der Datenbank gibt,
• die Reparatur fehlschlägt oder die Tabellen InnoDB sind,
• du keinen Zugang zu SFTP oder phpMyAdmin hast.

Bei der WordPress-Notfallhilfe reagieren wir in der Regel in unter zwei Stunden, sichern vor jedem Eingriff Datenbank und Dateien und rechnen nach einer kostenlosen Ersteinschätzung im 15-Minuten-Takt ab, mit 105 € pro Stunde zzgl. MwSt. Können wir den Fehler nicht beheben, gibt es keine Rechnung.

Damit du einen Ausfall künftig vor deinen Kunden bemerkst: In der WordPress-Betreuung überwachen wir die Seite rund um die Uhr und sichern sie täglich außerhalb des Hosters.

Häufige Fragen

Was bedeutet „Datenbankverbindung fehlgeschlagen“?

WordPress kann sich nicht mit der MySQL- oder MariaDB-Datenbank verbinden, in der alle Inhalte liegen. Ohne diese Verbindung kann es keine einzige Seite ausliefern. Deine Inhalte sind damit nicht automatisch weg. Meist ist nur die Verbindung gestört.

Kann ich die Datenbank selbst reparieren?

Mit WP_ALLOW_REPAIR ja, wenn die Tabellen MyISAM nutzen und du vorher ein Backup gemacht hast. Bei InnoDB-Tabellen hilft das Werkzeug kaum. Dann ist meist das Backup der richtige Weg.