MySQL nach Absturz retten

Wie schon in einem früheren Beitrag beschrieben, nutze ich für die Entwicklung meiner Applikationen und Webseiten die lokale XAMPP-Umgebung. Und wie damals hat mich das Thema MySQL nach einem unsauberen Herunterfahren des Rechners erneut eingeholt – diesmal allerdings mit einem etwas anderen Fehlerbild.

Das Problem

MySQL ließ sich im XAMPP Control Panel problemlos starten und blieb auch laufen. Trotzdem kam ich an meine Datenbanken nicht mehr heran. phpMyAdmin quittierte jeden Zugriff mit:

mysqli::real_connect(): (HY000/1130): Host 'localhost' is not allowed to connect to this MariaDB server

Das Kuriose daran: Der Server läuft, weist aber jede Verbindung ab – sogar die interne von phpMyAdmin. Es handelt sich also nicht um ein Passwort- oder Rechteproblem im üblichen Sinne.

Ein Blick in das Fehlerprotokoll (C:\apache\mysql\data\mysql_error.log) brachte schnell Klarheit:

[ERROR] InnoDB: ... log sequence number ... is in the future! ...
[ERROR] InnoDB: Your database may be corrupt or you may have copied the
InnoDB tablespace but not the InnoDB log files.

Der InnoDB-Tablespace ist also beschädigt. Dadurch kann MariaDB seine internen Rechte-Tabellen nicht mehr sauber laden – und weist deshalb pauschal alle Verbindungen mit dem Fehler 1130 ab. Die Ursache war, wie schon beim letzten Mal, mit hoher Wahrscheinlichkeit das Herunterfahren des Rechners, während MySQL noch lief.

Die gute Nachricht vorweg: Die Daten sind in aller Regel noch vollständig vorhanden. Man muss sie nur sauber herausholen.

Die Lösung in vier Schritten

Der Königsweg lautet: erst sichern, dann im Notmodus exportieren, anschließend ein frisches Datenverzeichnis aufsetzen und den Datenbestand zurückspielen.

1. Datenverzeichnis sichern

Bevor irgendetwas repariert wird, lege ich eine vollständige Kopie des Datenverzeichnisses an. So habe ich jederzeit einen Rückfallpunkt:

C:\apache\mysql\data   →   C:\apache\mysql\data_backup

2. MySQL im Notmodus starten

Damit der Server trotz Beschädigung wieder Verbindungen annimmt, starte ich MariaDB über die Eingabeaufforderung mit zwei zusätzlichen Parametern. Dieses Fenster bleibt geöffnet:

cd /d C:\apache\mysql\bin
mysqld --skip-grant-tables --innodb-force-recovery=1 --console

--innodb-force-recovery=1 bringt InnoDB trotz der Beschädigung zum Starten, und --skip-grant-tables umgeht die Prüfung der defekten Rechte-Tabellen.

3. Alle Datenbanken exportieren

In einem zweiten Fenster sichere ich nun den kompletten Datenbestand in eine SQL-Datei:

cd /d C:\apache\mysql\bin
mysqldump -u root --all-databases --routines --events --triggers > C:\apache\mysql\export.sql

Spätestens jetzt sind die Daten in Sicherheit.

4. Frisches Datenverzeichnis und Re-Import

XAMPP liefert im Ordner mysql\backup ein unberührtes, sauberes Datenverzeichnis mit. Genau das nutze ich für den Neuaufbau:

• den im Notmodus laufenden Server beenden (im ersten Fenster Strg + C)
• mysql\data in mysql\data_defekt umbenennen
• den Ordner mysql\backup kopieren und die Kopie in mysql\data umbenennen
• MySQL anschließend ganz normal über das XAMPP Control Panel starten

Zum Schluss spiele ich den gesicherten Datenbestand wieder ein:

cd /d C:\apache\mysql\bin
mysql -u root < C:\apache\mysql\export.sql

Danach ist phpMyAdmin wieder erreichbar und sämtliche Datenbanken sind vollständig vorhanden.

Fazit

Ein beschädigter InnoDB-Tablespace sieht im ersten Moment dramatisch aus: Der Server läuft, aber nichts geht mehr. Mit dem Notmodus (--innodb-force-recovery) lässt sich der Datenbestand jedoch zuverlässig sichern und über ein frisches Datenverzeichnis sauber wiederherstellen.

Und die wichtigste Lehre ist dieselbe wie beim letzten Mal: MySQL (und Apache) vor dem Herunterfahren des Rechners im XAMPP Control Panel ordnungsgemäß stoppen. Das erspart einem dieses kleine Abenteuer.

Ich hoffe, dieser Beitrag hilft dem Einen oder Anderen, im Ernstfall schnell und ohne Datenverlust wieder handlungsfähig zu sein.