In diesem Artikel wird hauptsächlich der Erfahrungsaustausch zur MySQL-Innodb-Ausnahmereparatur vorgestellt.
Eine Reihe von MySQL-Bibliotheken zum Testen vor . Später wollte ich Percona Server 5.7 ausprobieren, da diese Bibliothek keine wichtigen Daten enthält. Daher wurde vor dem Vorgang kein Backup durchgeführt. Nach der Konfiguration der Quelle wurde direkt die Installation durchgeführt. Die Datendateien werden auch am Standardspeicherort gespeichert. Nachdem die Installation abgeschlossen ist, starte ich MySQL direkt und stelle fest, dass der Start fehlschlägt und nicht normal gestartet werden kann.
1. Gehen Sie zurück und installieren Sie MySQL neu
Um den Aufwand des Importierens dieser Daten von anderen Orten zu vermeiden, erstellen Sie zunächst eine Sicherungskopie der aktuellen Datenbankdatei Bibliothek (/var/lib/mysql/location). Als nächstes deinstallierte ich das Percona-Serverpaket 5.7, installierte das ursprüngliche Paket 5.1.71 neu und startete den MySQL-Dienst. Es wurde die Meldung „Unbekannter/nicht unterstützter Tabellentyp: innodb“ angezeigt und konnte nicht normal gestartet werden.
110509 12:04:27 InnoDB: Initializing buffer pool, size = 384.0M 110509 12:04:27 InnoDB: Completed initialization of buffer pool InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes InnoDB: than specified in the .cnf file 0 157286400 bytes! 110509 12:04:27 [ERROR] Plugin 'InnoDB' init function returned error. 110509 12:04:27 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 110509 12:04:27 [ERROR] Unknown/unsupported table type: innodb 110509 12:04:27 [ERROR] Aborting 110509 12:04:27 [Note] /usr/sbin/mysqld: Shutdown complete
Löschen Sie das Verzeichnis /var/lib/mysql/, starten Sie den Datenbankdienst neu und initialisieren Sie ihn. Es wird festgestellt, dass Show Engines die Innodb-Engine finden können. Stoppen Sie dann die Datenbank, überschreiben Sie den Inhalt des zuvor gesicherten Verzeichnisses /var/lib/mysql/ mit dem Inhalt des aktuellen Speicherorts und starten Sie neu. Ich habe auch festgestellt, dass es nicht gestartet werden konnte und der Fehlerinhalt derselbe war wie zuvor.
Die Struktur des Inhalts des Verzeichnisses /var/lib/mysql ist wie folgt:
-rw-rw---- 1 mysql mysql 10485760 2月 26 18:10 ibdata1 -rw-rw---- 1 mysql mysql 5242880 2月 26 18:10 ib_logfile0 -rw-rw---- 1 mysql mysql 5242880 2月 26 17:20 ib_logfile1 drwx------ 2 mysql mysql 4096 2月 26 17:20 mysql drwx------ 2 mysql mysql 4096 2月 26 17:24 wiki
Das Wiki-Verzeichnis ist die Bibliothek für Testdaten, die Datei ibdata1 ist die Datendatei , und die beiden Dateien, die mit ib beginnen, sind Protokolldateien. Das MySQL-Verzeichnis enthält Dinge, die sich auf Systembibliotheken beziehen. Verwenden Sie die initialisierten Daten erneut und überschreiben Sie das Wiki-Verzeichnis und die Datei ibdata1 im Verzeichnis /var/lib/mysql. Sie können normal starten und sich anmelden.
2. Installieren Sie das Innodb-Modul neu
Beim Sichern über mysqldump wird jedoch die unbekannte Tabellen-Engine „Innodb“ angezeigt. Überprüfen Sie nach dem Anmelden alle aktuellen Engine-Typen und stellen Sie fest, dass der Typ innodb unter ihnen nicht vorhanden ist:
Verwenden Sie den Befehl alter, um den Typ einer der Tabellen zu ändern zu MyISAM und stellen Sie fest, dass der Fehler immer noch gemeldet wird.
Verwenden Sie find, um herauszufinden, dass sich im Verzeichnis /usr/lib64/mysql/plugin/ eine Datei ha_innodb_plugin.so befindet. Ich habe den Eindruck, dass spätere Versionen von MySQL5 die Online-Plugin-Installation unterstützen. Überprüfen Sie Folgendes, um sicherzustellen, dass es tatsächlich unterstützt wird:
Beim Laden mit dem folgenden Befehl wurde festgestellt, dass der Vorgang nicht erfolgreich war:
install plugin innodb soname 'ha_innodb.so';
3. Backup
Fügen Sie die folgende Konfiguration in /etc/my.cnf hinzu:
plugin-load=innodb=ha_innodb_plugin.so plugin_dir=/usr/lib64/mysql/plugin/ default-storage-engine=InnoDB
Es wurde festgestellt, dass der Start immer noch fehlschlägt. Überprüfen Sie mysql-error.log und finden Sie den folgenden Inhalt:
InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 7. InnoDB: You may have to recover from a backup. InnoDB: It is also possible that your operating InnoDB: system has corrupted its own file cache InnoDB: and rebooting your computer removes the InnoDB: error. InnoDB: If the corrupt page is an index page InnoDB: you can also try to fix the corruption InnoDB: by dumping, dropping, and reimporting InnoDB: the corrupt table. You can use CHECK InnoDB: TABLE to scan your table for corruption. InnoDB: See also http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html
Öffnen Sie die offizielle Seite „forcing-innodb-recovery“ und stellen Sie fest, dass Sie den Start und die Wiederherstellung erzwingen können, indem Sie den Parameter „innodb_force_recovery“ angeben. Fügen Sie den folgenden Inhalt zu /etc/my.cnf hinzu:
innodb_force_recovery=6
Der Neustart war erfolgreich. Das Sichern über mysqldump stellt kein Problem dar. Auch das Importieren der Sicherungsdaten auf andere Hosts ist normal und kann getestet werden.
Jetzt ist es ganz einfach, MySQL vollständig zu löschen und Percona Server 5.7 neu zu installieren. Nach der Installation die Datenbank erstellen, die Daten wiederherstellen, das Programm erneut verbinden und alles ist in Ordnung.
Zusammenfassung:
Aufgrund der Eigenschaften von MySQL-Innodb-Datendateien können Sie zuerst ./ib_logfile0 und ./ib_logfile1 protokollieren, wenn ein Problem auftritt und nicht normal gestartet werden kann Verschieben Sie zuerst die Datei und starten Sie sie dann. Wenn der Vorgang immer noch fehlschlägt, können Sie die Wiederherstellung mit dem Parameter innodb_force_recovery erzwingen. Darüber hinaus ist das Protokoll auch sehr gut wiederstartbar. Wenn Sie Fragen haben, überprüfen Sie zunächst das Protokoll.
Das obige ist der detaillierte Inhalt vonBeispiel für einen MySQL-Innodb-Ausnahmereparaturprozess. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!