Skip navigation links
14.2.8.2 Checkpoints »
Section Navigation      [Toggle]

14.2.8.1. Erzwingen einer InnoDB-Wiederherstellung (Recovery)

Wenn Schäden an Datenbankseiten vorhanden sind, sollten Sie Ihre Tabellen mit SELECT INTO OUTFILE dumpen. Normalerweise sind die meisten auf diese Weise geretteten Daten intakt. Trotzdem kann der Schaden dazu führen, dass SELECT * FROM tbl_name-Anweisungen oder InnoDB-Hintergrundoperationen abstürzen oder sich durchsetzen oder gar die Roll-forward-Recovery von InnoDB abstürzen lassen. Sie können einen Neustart von InnoDB erzwingen und gleichzeitig die Hintergrundoperationen anhalten, sodass ein Tabellen-Dump möglich ist. Zum Beispiel könnten Sie dem Abschnitt [mysqld] Ihrer Optionsdatei vor dem Server-Neustart folgende Zeile hinzufügen: 

[mysqld]
innodb_force_recovery = 4

Weiter unten erfahren Sie, welche von null verschiedenen Werte innodb_force_recovery annehmen kann. Größere Werte schließen alle Sicherheitsmaßnahmen der kleineren Werte mit ein. Wenn Sie in der Lage sind, Ihre Tabellen mit einem Optionswert von höchstens 4 zu dumpen, können Sie davon ausgehen, dass nur wenige Daten auf einzelnen beschädigten Seiten verloren gegangen sind. Der Wert 6 ist schon drastischer: Hier bleiben Datenbankseiten in einem obsoleten Zustand zurück, was zu zusätzlichen Schäden in B-Bäumen und anderen Datenbankstrukturen führen kann.

  • 1 (SRV_FORCE_IGNORE_CORRUPT)

    Server soll auch dann weiter laufen, wenn er eine beschädigte Seite entdeckt. Versuchen Sie, SELECT * FROM tbl_name beschädigte Indexeinträge und Seiten überspringen zu lassen, da dies den Tabellen-Dump erleichtert.

  • 2 (SRV_FORCE_NO_BACKGROUND)

    Unterbindet den Haupt-Thread. Wenn während der Purge-Operation ein Absturz passiert, wird dieser Recovery-Wert das verhindern.

  • 3 (SRV_FORCE_NO_TRX_UNDO)

    Nach der Recovery keine Transaktionen zurückrollen.

  • 4 (SRV_FORCE_NO_IBUF_MERGE)

    Verhindert auch Merge-Operationen auf Insert-Puffern. Wenn diese einen Absturz herbeiführen würden werden sie nicht durchgeführt. Es wird keine Tabellenstatistik berechnet.

  • 5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

    Beim Starten der Datenbank nicht in die Undo-Logs schauen: InnoDB behandelt dann auch unvollständige Transaktionen als abgeschlossen.

  • 6 (SRV_FORCE_NO_LOG_REDO)

    Keinen Roll-forward der Logs in Verbindung mit der Recovery durchführen.

Selbst bei einer erzwungenen Recovery können Sie Tabellen mit SELECT dumpen oder sie mit DROP löschen oder mit CREATE anlegen. Wenn Sie wissen, dass eine bestimmte Tabelle beim Zurückrollen einen Absturz verursacht, können Sie sie löschen. Oder Sie verwenden diese Option, um ein Rollback anzuhalten, das wegen eines gescheiterten Massen-Imports oder einer fehlgeschlagenen ALTER TABLE-Operation außer Kontrolle geraten ist. Sie können den mysqld-Prozess anhalten und innodb_force_recovery auf 3 setzen, um die Datenbank ohne den Rollback wieder ans Laufen zu bringen, und dann mit DROP die Tabelle löschen, die den Endlos-Rollback verursacht hatte.

Die Datenbank darf auf keine andere Weise mit einem von null verschiedenen innodb_force_recovery-Wert benutzt werden. Zur Sicherheit hindert InnoDB die Benutzer an INSERT-, UPDATE- und DELETE-Operationen, wenn innodb_force_recovery größer als 0 ist.

Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.