Seite gesperrt

Diese Seite ist momentan von einem anderen Benutzer gesperrt. Warte, bis dieser mit dem Bearbeiten fertig ist oder die Sperre abläuft.

Momentan gesperrt von:
Sperre läuft ab am: 29.10.2026 21:42 (15 min)

Eine ältere Version des Dokuments wurde geladen! Beim Speichern wird eine neue Version des Dokuments mit diesem Inhalt erstellt.

<WRAP rww-topic-heading>
====== MariaDB-Recovery nach InnoDB-Absturz ======
</WRAP>

</WRAP>

Diese Anleitung dokumentiert die erfolgreiche Wiederherstellung einer beschädigten lokalen MariaDB-Installation.

Sie basiert auf einem konkreten Recovery-Fall vom **17.08.2026** unter Windows mit XAMPP und MariaDB 10.4.32.

<WRAP rww-back>
[[werkzeuge:mariadb:start|←]] [[werkzeuge:mariadb:start|MariaDB]]
</WRAP>

----

===== Ausgangslage =====

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

XAMPP meldete:

<code>
Fehler: MySQL wurde unerwartet beendet
</code>

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:

<code>
thecruiserblog_local
</code>

===== Ziel des Recovery-Verfahrens =====

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

Stattdessen wurde folgendes Vorgehen gewählt:

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

===== 1. Erste Diagnose =====

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

<code cmd>
netstat -ano | findstr :3306
</code>

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

==== MariaDB direkt in der Konsole starten ====

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

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

Der direkte Konsolenstart zeigte anschließend die konkrete Fehlermeldung.

===== 2. Beschädigte Aria-Systemtabelle =====

Der Konsolenstart zeigte zunächst folgende Fehlermeldung:

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

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

==== Tabellentyp feststellen ====

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

<code cmd>
dir E:\xampp\mysql\data\mysql\db.*
</code>

Vorhanden waren:

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

==== Aria-Tabelle reparieren ====

Vor der Reparatur muss MariaDB vollständig gestoppt sein.

Die beschädigte Tabelle wurde mit ''aria_chk'' repariert:

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

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

<code>
Wrong CRC on datapage at 1
- Fixing index 1
- Fixing index 2
State updated
</code>

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:

<WRAP important>
Die beschädigte Aria-Systemtabelle war nicht die einzige Ursache. Es musste eine weitere Diagnose des MariaDB-Datenbestands erfolgen.
</WRAP>

===== 3. InnoDB-Schaden feststellen =====

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:

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

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

<code>
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)
</code>

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

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

==== Wichtig: Keine vorschnellen Eingriffe ====

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

Insbesondere wurden folgende Dateien nicht verändert:

<code>
ibdata1
ib_logfile*
</code>

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

<WRAP important>
Bei einem InnoDB-Schaden sollte der vorhandene Datenbestand zunächst erhalten bleiben.

Das erste Ziel ist die **Rettung der Daten**, nicht die Reparatur durch Löschen oder Austauschen zentraler InnoDB-Dateien.
</WRAP>

==== Entscheidung für den Recovery-Modus ====

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.

===== 4. InnoDB-Recovery-Modus =====

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

Die Konfigurationsdatei befindet sich in dieser Installation unter:

<code>
E:\xampp\mysql\bin\my.ini
</code>

Unterhalb des Abschnitts

<code ini>
[mysqld]
</code>

wurde zunächst folgende Zeile ergänzt:

<code ini>
innodb_force_recovery=1
</code>

MariaDB startete damit weiterhin nicht.

==== Recovery-Level schrittweise erhöhen ====

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:

^ Recovery-Level ^ Ergebnis ^
| ''1'' | MariaDB stürzt ab |
| ''2'' | MariaDB stürzt ab |
| ''3'' | MariaDB stürzt ab |
| ''4'' | MariaDB stürzt ab |
| ''5'' | MariaDB stürzt ab |
| ''6'' | **MariaDB startet** |

Erst mit:

<code ini>
innodb_force_recovery=6
</code>

blieb MariaDB gestartet.

==== Recovery-Modus dient nur zur Datenrettung ====

<WRAP important>
''innodb_force_recovery'' repariert die beschädigte InnoDB-Datenbank **nicht**.

Der Recovery-Modus dient dazu, einen beschädigten Datenbestand möglichst noch lesbar zu machen, damit wichtige Daten exportiert werden können.
</WRAP>

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

==== Grundregel für den Recovery-Level ====

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

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

<WRAP tip>
Immer den **niedrigsten Recovery-Level verwenden, mit dem MariaDB startet**.

Im konkreten Fall war Level 6 notwendig.
</WRAP>

===== 5. Datenbanken sichern =====

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

Die wichtigste Datenbank war:

<code>
thecruiserblog_local
</code>

==== TCB-Datenbank mit WP-CLI exportieren ====

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:

<code cmd>
cd /d E:\xampp\htdocs\thecruiserblog
</code>

Anschließend wurde der Datenbank-Dump erstellt:

<code cmd>
wp db export E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql
</code>

WP-CLI bestätigte den erfolgreichen Export:

<code>
Success: Exported to 'E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql'.
</code>

==== SQL-Dump kontrollieren ====

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

<code cmd>
dir E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql
</code>

Der erzeugte Dump hatte eine Größe von:

<code>
8.859.273 Bytes
</code>

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

<WRAP important>
Eine Erfolgsmeldung allein sollte nicht genügen.

Nach einem Recovery-Export immer zusätzlich prüfen, ob die SQL-Datei tatsächlich vorhanden ist und eine plausible Dateigröße besitzt.
</WRAP>

==== SQL-Dump zusätzlich extern sichern ====

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.

==== Vorhandene Datenbanken anzeigen ====

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

<code cmd>
E:\xampp\mysql\bin\mysql.exe -u root -e "SHOW DATABASES;"
</code>

Die Ausgabe enthielt:

<code>
information_schema
mysql
performance_schema
phpmyadmin
rowakecms
rowakewp
test
thecruiserblog_local
</code>

Die Datenbanken

<code>
information_schema
mysql
performance_schema
phpmyadmin
</code>

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

Eigene Datenbanken waren:

<code>
rowakecms
rowakewp
test
thecruiserblog_local
</code>

==== Weitere Datenbanken sichern ====

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

Beispiel:

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

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:

<WRAP tip>
Solange eine beschädigte MariaDB-Installation im Recovery-Modus noch lesbar ist, lieber eine möglicherweise nicht mehr benötigte eigene Datenbank zusätzlich exportieren als sie später zu vermissen.
</WRAP>

==== Ergebnis der logischen Datensicherung ====

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

<code>
TCB_recovery_20260817.sql
</code>

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

Zusammenfassung