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: 216.73.217.32
Sperre läuft ab am: 29.10.2026 21:42 (15 min)
Diese Seite ist nicht editierbar. Du kannst den Quelltext sehen, jedoch nicht verändern. Kontaktiere den Administrator, wenn du glaubst, dass hier ein Fehler vorliegt.
<WRAP rww-topic-header>

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

<WRAP rww-topic-symbol>
<iconify mdi:database-alert>
</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:

<code>
db.frm
db.MAD
db.MAI
</code>

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.