Erfahrungsaustausch zur Reparatur von MySQL InnoDB-Ausnahmen

Eine Reihe von MySQL-Bibliotheken zum Testen. Die zuvor verwendete Version war MySQL 5.1.71 in der Standardquelle von centos6. Später wollte ich Percona Server 5.7 ausprobieren, da in dieser Bibliothek keine wichtigen Daten vorhanden waren. Daher wurde vor der Operation kein Backup durchgeführt. Nach der Konfiguration der Quelle wurde direkt die Installation durchgeführt. Die Datendateien werden auch am Standardspeicherort gespeichert. Starten Sie MySQL nach Abschluss der Installation direkt und stellen Sie fest, dass der Start fehlschlägt und dass es nicht normal gestartet werden kann.

1. Rollback und Neuinstallation von MySQL

Um den Aufwand beim Importieren dieser Daten von anderen Orten zu vermeiden, erstellen Sie zunächst eine Sicherungskopie der Datenbankdatei der aktuellen Bibliothek (Speicherort /var/lib/mysql/). Als Nächstes habe ich das Percona Server 5.7-Paket deinstalliert, das alte 5.1.71-Paket neu installiert, den MySQL-Dienst gestartet und die Meldung „Unbekannter/nicht unterstützter Tabellentyp: innodb“ angezeigt und konnte nicht normal gestartet werden.

110509 12:04:27 InnoDB: Pufferpool wird initialisiert, Größe = 384,0 M
110509 12:04:27 InnoDB: Initialisierung des Pufferpools abgeschlossen
InnoDB: Fehler: Protokolldatei ./ib_logfile0 hat eine andere Größe 0 5242880 Bytes
InnoDB: als in der .cnf-Datei angegeben 0 157286400 Bytes!
110509 12:04:27 [FEHLER] Die Initialisierungsfunktion des Plugins „InnoDB“ hat einen Fehler zurückgegeben.
110509 12:04:27 [FEHLER] Die Registrierung des Plugins „InnoDB“ als STORAGE ENGINE ist fehlgeschlagen.
110509 12:04:27 [FEHLER] Unbekannter/nicht unterstützter Tabellentyp: innodb
110509 12:04:27 [FEHLER] Abbruch
110509 12:04:27 [Hinweis] /usr/sbin/mysqld: Herunterfahren abgeschlossen

Löschen Sie das Verzeichnis /var/lib/mysql/, starten Sie den Datenbankdienst neu und initialisieren Sie ihn. Das ist normal. Der Befehl „show engines“ kann feststellen, dass eine InnoDB-Engine vorhanden ist. Stoppen Sie die Datenbank erneut, überschreiben Sie den Inhalt des zuvor gesicherten Verzeichnisses /var/lib/mysql/ mit dem Inhalt des aktuellen Speicherorts und starten Sie neu. Es wurde festgestellt, dass es nicht gestartet werden konnte und der Fehlerinhalt derselbe war wie zuvor.

Die Struktur des Verzeichnisinhalts /var/lib/mysql ist wie folgt:

-rw-rw---- 1 mysql mysql 10485760 26. Februar 18:10 ibdata1
-rw-rw---- 1 mysql mysql 5242880 26. Februar 18:10 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 26. Februar 17:20 ib_logfile1
drwx------ 2 mysql mysql 4096 26. Februar 17:20 mysql
drwx------ 2 mysql mysql 4096 Februar 26 17:24 wiki

Das Wiki-Verzeichnis ist die Bibliothek für Testdaten, die Datei ibdata1 ist die Datendatei, die beiden Dateien, die mit ib beginnen, sind Protokolldateien und das MySQL-Verzeichnis enthält Dinge, die mit der Systembibliothek in Zusammenhang stehen. Verwenden Sie die initialisierten Daten erneut und überschreiben Sie das Wiki-Verzeichnis und die ibdata1-Datei in das Verzeichnis /var/lib/mysql. Sie können normal starten und sich anmelden.

2. InnoDB-Modul neu installieren

Beim Sichern über mysqldump wird jedoch die Meldung „Unbekannte Tabellen-Engine „Innodb““ angezeigt. Nach dem Einloggen habe ich alle aktuellen Engine-Typen überprüft und festgestellt, dass tatsächlich kein InnoDB-Typ vorhanden war:

Ich habe den ALTER-Befehl verwendet, um den Typ einer der Tabellen in MyISAM zu ändern, habe jedoch festgestellt, dass der Fehler weiterhin auftrat.

Durch Suchen haben wir festgestellt, dass sich im Verzeichnis /usr/lib64/mysql/plugin/ eine Datei ha_innodb_plugin.so befindet. Ich habe den Eindruck, dass Versionen nach MySQL 5 die Online-Installation von Plug-Ins unterstützen. Überprüfen und bestätigen Sie unten, dass es tatsächlich unterstützt wird:

Beim Laden mit folgendem Befehl konnte kein Erfolg festgestellt werden:

Installieren Sie das Plugin InnoDB mit dem Sonamen „ha_innodb.so“.

3. Sicherung

Fügen Sie die folgende Konfiguration in /etc/my.cnf hinzu:

Plugin-Laden = innodb = ha_innodb_plugin.so
plugin_dir=/usr/lib64/mysql/plugin/
Standard-Speicher-Engine = InnoDB

Es stellte sich heraus, dass der Start immer noch fehlschlug. Beim Überprüfen von mysql-error.log habe ich Folgendes gefunden:

InnoDB: Datenbankseitenbeschädigung auf der Festplatte oder ein
InnoDB: Datei lesen von Seite 7.
InnoDB: Möglicherweise müssen Sie eine Wiederherstellung aus einer Sicherung durchführen.
InnoDB: Es ist auch möglich, dass Ihr Betriebssystem
InnoDB: Das System hat seinen eigenen Dateicache beschädigt
InnoDB: und ein Neustart Ihres Computers entfernt die
InnoDB: Fehler.
InnoDB: Wenn die beschädigte Seite eine Indexseite ist
InnoDB: Sie können auch versuchen, die Beschädigung zu beheben
InnoDB: durch Dumping, Dropping und Reimport
InnoDB: die beschädigte Tabelle. Sie können CHECK verwenden
InnoDB: TABLE, um Ihre Tabelle auf Beschädigungen zu überprüfen.
InnoDB: Siehe auch http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html

Öffnen Sie die offizielle Seite zum Erzwingen der Innodb-Recovery und sehen Sie, dass Sie den Start und die Wiederherstellung durch Angabe des Parameters innodb_force_recovery erzwingen können. Fügen Sie den folgenden Inhalt zu /etc/my.cnf hinzu:

innodb_force_recovery=6

Der Neustart war erfolgreich. Das Sichern über mysqldump ist kein Problem und auch das Einspielen der Backup-Daten auf andere Hosts funktioniert problemlos und lässt sich testen.

Das geht ganz einfach. Löschen Sie MySQL vollständig und installieren Sie Percona Server 5.7 neu. Erstellen Sie nach der Installation eine Datenbank, stellen Sie die Daten wieder her, verbinden Sie das Programm erneut und alles ist in Ordnung.

Zusammenfassen:

Aufgrund der Eigenschaften von MySQL-InnoDB-Datendateien können Sie bei Problemen, die dazu führen, dass das System nicht normal gestartet werden kann, zunächst die beiden Protokolldateien ./ib_logfile0 und ./ib_logfile1 verschieben und dann neu starten. Wenn dies fehlschlägt, können Sie die Wiederherstellung mit dem Parameter innodb_force_recovery erzwingen. Darüber hinaus ist das Protokoll auch sehr gut neu startbar. Wenn Sie Fragen haben, lesen Sie zuerst das Protokoll.