MariaDB ließ sich über das XAMPP Control Panel nicht mehr dauerhaft starten.

XAMPP meldete:

Fehler: MySQL wurde unerwartet beendet

Im Verlauf der Diagnose wurden zwei unterschiedliche Schäden festgestellt:

• beschädigte Aria-Systemtabelle mysql.db
• anschließender InnoDB-Absturz während der Crash-Recovery

Die wichtigste zu rettende Datenbank war:

thecruiserblog_local

Ziel war nicht, die beschädigte MariaDB-Installation dauerhaft weiterzuverwenden.

Stattdessen wurde folgendes Vorgehen gewählt:

1. Ursache des Fehlers feststellen
2. Daten möglichst sicher exportieren
3. beschädigten Datenbestand zusätzlich sichern
4. MariaDB sauber neu initialisieren
5. benötigte Datenbank aus dem SQL-Dump wiederherstellen

Zunächst wurde geprüft, ob der MariaDB-Standard-Port 3306 bereits von einem anderen Prozess verwendet wurde.

netstat -ano | findstr :3306

Im konkreten Fall gab es keine Ausgabe. Ein Portkonflikt konnte damit ausgeschlossen werden.

Um die eigentliche Ursache sichtbar zu machen, wurde MariaDB direkt über die Windows-Eingabeaufforderung gestartet:

cd /d E:\xampp\mysql\bin
mysqld.exe --defaults-file="E:\xampp\mysql\bin\my.ini" --console

Der direkte Konsolenstart zeigte anschließend die konkrete Fehlermeldung.

Der Konsolenstart zeigte zunächst folgende Fehlermeldung:

Table '.\mysql\db' is marked as crashed and last (automatic?) repair failed
Fatal error: Can't open and lock privilege tables

Damit war die MariaDB-Systemtabelle mysql.db als beschädigt erkannt.

Zunächst wurden die zugehörigen Dateien geprüft:

dir E:\xampp\mysql\data\mysql\db.*

Vorhanden waren:

db.frm
db.MAD
db.MAI

Die Dateiendungen .MAD und .MAI zeigen, dass es sich um eine Aria-Tabelle handelt.

Vor der Reparatur muss MariaDB vollständig gestoppt sein.

Die beschädigte Tabelle wurde mit aria_chk repariert:

cd /d E:\xampp\mysql\bin
aria_chk.exe -r E:\xampp\mysql\data\mysql\db.MAI

Während der Reparatur wurden unter anderem folgende Meldungen ausgegeben:

Wrong CRC on datapage at 1
- Fixing index 1
- Fixing index 2
State updated

Die Meldung Wrong CRC on datapage bestätigte eine beschädigte Datenseite.

Nach der Reparatur ließ sich MariaDB zunächst wieder starten.

Beim anschließenden Zugriff auf WordPress stürzte MariaDB jedoch erneut ab.

Damit war klar:

Nach der Reparatur der Aria-Systemtabelle ließ sich MariaDB zunächst starten, stürzte beim Zugriff auf WordPress jedoch erneut ab.

Deshalb wurde MariaDB nochmals direkt über die Konsole gestartet:

cd /d E:\xampp\mysql\bin
mysqld.exe --defaults-file="E:\xampp\mysql\bin\my.ini" --console

Diesmal erschien während der InnoDB-Crash-Recovery die entscheidende Fehlermeldung:

InnoDB: Starting crash recovery from checkpoint LSN=58097070
InnoDB: Starting final batch to recover 2 pages from redo log.

[FATAL] InnoDB: Trying to read page number 14650 in space 0,
space name innodb_system, which is outside the tablespace bounds.

Please check that the configuration matches the
InnoDB system tablespace location (ibdata files)

Damit war klar, dass zusätzlich ein Problem im InnoDB-System-Tablespace vorlag.

Der normale Start von MariaDB war nicht mehr möglich.

An diesem Punkt wurden bewusst keine InnoDB-Dateien gelöscht oder ersetzt.

Insbesondere wurden folgende Dateien nicht verändert:

ibdata1
ib_logfile*

Auch der vorhandene MariaDB-Datenordner wurde nicht gelöscht.

Da MariaDB nicht mehr normal gestartet werden konnte, wurde als nächster Schritt der InnoDB-Recovery-Modus verwendet.

Dabei sollte zunächst der niedrigste Recovery-Level getestet und nur bei Bedarf schrittweise erhöht werden.

Für die Datenrettung wurde in der MariaDB-Konfiguration der Parameter innodb_force_recovery verwendet.

Die Konfigurationsdatei befindet sich in dieser Installation unter:

E:\xampp\mysql\bin\my.ini

Unterhalb des Abschnitts

[mysqld]

wurde zunächst folgende Zeile ergänzt:

innodb_force_recovery=1

MariaDB startete damit weiterhin nicht.

Der Wert wurde deshalb schrittweise erhöht.

Nach jeder Änderung wurde my.ini gespeichert und MariaDB erneut über das XAMPP Control Panel gestartet.

Das Ergebnis des konkreten Recovery-Falls:

Erst mit:

innodb_force_recovery=6

blieb MariaDB gestartet.

Deshalb wurde MariaDB mit Recovery-Level 6 nicht wieder normal verwendet.

Insbesondere wurde:

• TheCruiserBlog nicht im Browser geöffnet
• nicht mit WordPress weitergearbeitet
• keine Datenbankänderung durchgeführt
• unmittelbar mit der Datensicherung begonnen

Es sollte immer mit dem niedrigsten Recovery-Level begonnen werden:

1 → 2 → 3 → 4 → 5 → 6

Nur wenn MariaDB mit dem jeweiligen Level nicht startet, wird der Wert erhöht.

Nachdem MariaDB mit innodb_force_recovery=6 gestartet war, wurde sofort mit der Datensicherung begonnen.

Die wichtigste Datenbank war:

thecruiserblog_local

Da WP-CLI für TheCruiserBlog bereits eingerichtet war, wurde die Datenbank direkt aus dem WordPress-Verzeichnis exportiert.

Zunächst wurde in das Projektverzeichnis gewechselt:

cd /d E:\xampp\htdocs\thecruiserblog

Anschließend wurde der Datenbank-Dump erstellt:

wp db export E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql

WP-CLI bestätigte den erfolgreichen Export:

Success: Exported to 'E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql'.

Nach dem Export wurde geprüft, ob die Datei tatsächlich vorhanden war:

dir E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql

Der erzeugte Dump hatte eine Größe von:

8.859.273 Bytes

Damit lag eine plausible SQL-Sicherung der TCB-Datenbank vor.

Der erzeugte Dump wurde anschließend zusätzlich außerhalb des XAMPP-Bereichs gesichert.

Damit blieb die Datenbanksicherung auch dann erhalten, wenn beim späteren Neuaufbau der lokalen MariaDB-Installation etwas schiefgehen sollte.

Bevor MariaDB neu aufgebaut wurde, wurden alle vorhandenen Datenbanken aufgelistet:

E:\xampp\mysql\bin\mysql.exe -u root -e "SHOW DATABASES;"

Die Ausgabe enthielt:

information_schema
mysql
performance_schema
phpmyadmin
rowakecms
rowakewp
test
thecruiserblog_local

Die Datenbanken

information_schema
mysql
performance_schema
phpmyadmin

gehörten zum MariaDB-/XAMPP-System und waren nicht die Grundlage für die spätere Wiederherstellung.

Eigene Datenbanken waren:

rowakecms
rowakewp
test
thecruiserblog_local

Solange MariaDB im Recovery-Modus noch lief, wurden vorsichtshalber auch die übrigen eigenen Datenbanken exportiert.

Beispiel:

E:\xampp\mysql\bin\mysqldump.exe -u root rowakecms > E:\xampp\htdocs\rowakecms_recovery_20260817.sql

Analog wurden auch rowakewp und test gesichert.

Später stellte sich heraus, dass diese drei Datenbanken nicht mehr benötigt wurden.

Die Sicherung war trotzdem sinnvoll:

Für die benötigte TCB-Datenbank stand nun ein eigenständiger SQL-Dump zur Verfügung:

TCB_recovery_20260817.sql

Damit war die wichtigste Voraussetzung für den anschließenden Neuaufbau von MariaDB erfüllt.