Beheben Sie das Problem, dass die MySQL-Datenbank unerwartet abstürzt, wodurch die Tabellendatendatei beschädigt wird und nicht gestartet werden kann

Problem:

Die MySQL-Datenbank ist unerwartet abgestürzt und konnte nicht gestartet werden.

Fehlerprotokoll:

Startfehler: Dienst mysqld neu gestartet

FEHLER! Die PID-Datei des MySQL-Servers konnte nicht gefunden werden!
MySQL wird gestartet. FEHLER! Der Server wurde beendet, ohne die PID-Datei (/www/wdlinux/mysql/var/iZ2358oz5deZ.pid) zu aktualisieren.

Datenbank-Fehlerprotokoll:

200719 22:07:43 InnoDB: Datenbank wurde nicht normal heruntergefahren!
InnoDB: Absturzwiederherstellung wird gestartet.
InnoDB: Tablespace-Informationen aus den .ibd-Dateien lesen …
InnoDB: Fehler: Beim Versuch, Tablespace 840 mit dem Namen „./ob_wp/ob_termmeta.ibd“ hinzuzufügen.
InnoDB: zum Tablespace-Speicher-Cache, aber Tablespace
InnoDB: 840 mit dem Namen „./dev_nss/dg_queue.ibd“ existiert bereits im Tablespace
InnoDB: Speichercache!
200719 22:07:43 mysqld_safe mysqld aus PID-Datei /www/wdlinux/mysql/var/iZ2358oz5deZ.pid beendet

Tipp: Wenn die Tabellenbereichsinformationen beim Start der Datenbank gelesen werden, ist die Datendatei der Tabelle ob_users.ibd in der Bibliothek ob-wp bereits im Tabellenbereich vorhanden.

expandieren:

Die Speicher-Engine ist myisam. Im Datenbankverzeichnis finden Sie drei Dateitypen: .frm, .myi und .myd
(a) *.frm – Tabellendefinition, eine Datei, die die Tabellenstruktur beschreibt.
(b) *.MYD--„D“-Dateninformationsdatei, die die Datendatei der Tabelle ist.
(c) *.MYI – „I“-Indexinformationsdatei, die den Datenbaum aller Indizes in der Tabellendatendatei darstellt. Die Speicher-Engine ist InnoDB. Im Datenverzeichnis gibt es zwei Dateitypen: .frm und .ibd
(a) *.frm-Datei mit Tabellenstruktur.
(b) *.ibd – Tabellendatendatei

Quelle: https://www.cnblogs.com/liucx/

Methode 1:

Gemäß den Eingabeaufforderungsinformationen wird festgestellt, dass die InnoDB-Tabelle beschädigt ist. Versuchen Sie daher, die Tabellenstruktur und die Tabellendatendateien im Bibliotheksverzeichnis dev_nss zu sichern.
mv ob_termmeta.ibd ob_termmeta.ibd,bak
mv ob_termmeta.frm ob_termmeta.frm.bak
Dann habe ich MySQL neu gestartet, konnte es aber immer noch nicht starten. Es wurde angezeigt, dass bereits andere Tabellendatendateien vorhanden waren. Ich habe die beschädigten Dateien dreimal hintereinander gesichert, konnte es aber immer noch nicht starten. Daher wird von dieser Methode Abstand genommen.

Methode 2:

1. Konsultieren Sie die Dokumentation der offiziellen Website, fügen Sie der MySQL-Konfigurationsdatei /etc/my.cnf eine Konfiguration hinzu und starten Sie erfolgreich
[mysqld]
innodb_force_recovery = 1

2. Sichern Sie die Datenbank
mysqldump -h172.168.2.100 -uroot -p -A > mysql_all_bak.sql
Wenn der Bericht nicht existiert, kann mysqldump den Parameter --force hinzufügen, um den Fehler zu überspringen

3. Löschen Sie die Datenbank
Datenbank hxdb löschen; oder mv hxdb hxdb_bak (aus Sicherheitsgründen)

4. Entfernen Sie den Parameter innodb_force_recovery
Nach dem Entfernen der zuvor eingestellten Parameter starten Sie die Datenbank neu

5. Daten importieren
mysql -uroot -p < mysql_all_bak.sql
Warnung: Die Verwendung eines Kennworts in der Befehlszeilenschnittstelle kann unsicher sein.
FEHLER 1050 (42S01) in Zeile 25: Tabelle „hxdb“. „tb_info“ existiert bereits

Wenn die Meldung angezeigt wird, dass die Tabelle bereits vorhanden ist, liegt dies daran, dass die Datenbank nach dem Entfernen des Parameters innodb_force_recovery ein Rollback durchführt und die entsprechende IBD-Datei generiert. Sie müssen die Datei daher löschen und erneut importieren.
mysql -uroot -p < mysql_all_bak.sql

Notiz:

Erklärung des Parameters innodb_force_recovery: Absturzwiederherstellungsmodus, wird normalerweise nur in schwerwiegenden Fehlerbehebungssituationen geändert. Mögliche Werte sind 0 bis 6.

Setzen Sie diese Variable nur im Notfall auf einen Wert größer als 0, damit Sie InnoDB starten und Ihre Tabellen sichern können. Als Sicherheitsmaßnahme verhindert InnoDB Einfüge-, Aktualisierungs- oder Löschvorgänge, wenn innodb_force_recovery größer als 0 ist.
In 5.6.15 wird innodb_force_recovery auf 4 oder höher gesetzt, um InnoDB in den schreibgeschützten Modus zu versetzen. Da relay_log_info_repository=TABLE und master_info_repository=TABLE Informationen in InnoDB-Tabellen speichern, können diese Einschränkungen dazu führen, dass Replikationsverwaltungsbefehle mit Fehlern fehlschlagen.

innodb_force_recovery ist standardmäßig 0 (normaler Start ohne erzwungene Wiederherstellung). Zulässige Werte ungleich Null für innodb_force_recovery sind 1 bis 6. Größere Werte beinhalten die Funktionalität kleinerer Werte. Beispielsweise enthält der Wert 3 alle Merkmale der Werte 1 und 2.
Wenn Sie die Tabelle mit einem innodb_force_recovery-Wert von 3 oder weniger sichern können, besteht für Sie eine relativ geringe Gefahr, dass nur einige der Daten einer einzigen beschädigten Seite verloren gehen. Werte von 4 oder höher gelten als gefährlich, da Datendateien dauerhaft beschädigt werden können. Ein Wert von 6 wird als zu hoch angesehen, da Datenbankseiten in einem veralteten Zustand belassen werden, was wiederum B-Bäume und andere Datenbankstrukturen einer stärkeren Beschädigung aussetzen kann.

Aus Sicherheitsgründen verhindert InnoDB INSERT-, UPDATE- oder DELETE-Operationen, wenn innodb_force_recovery größer als 0 ist. Ab MySQL 5.6.15 wird InnoDB in den schreibgeschützten Modus versetzt, wenn innodb_force_recovery auf 4 oder mehr gesetzt wird.
1 (SRV_FORCE_IGNORE_CORRUPT)
Lassen Sie den Server weiterlaufen, auch wenn er eine beschädigte Seite erkennt. Versuchen Sie, mit SELECT * FROM tbl_name beschädigte Indexdatensätze und Seiten überspringen zu lassen. Dies kann beim Sichern der Tabelle hilfreich sein.
2 (SRV_FORCE_NO_BACKGROUND)
Blockiert die Ausführung des Hauptthreads und aller Bereinigungsthreads. Wenn während eines Bereinigungsvorgangs ein Absturz auftritt, verhindert dieser Wiederherstellungswert den Absturz.
3 (SRV_FORCE_NO_TRX_UNDO)
Führen Sie nach der Wiederherstellung nach einem Absturz kein Transaktions-Rollback aus.
4 (SRV_FORCE_NO_IBUF_MERGE)
Verhindert Zusammenführungsvorgänge beim Einfügepuffer. Wenn sie einen Unfall verursachen, führen Sie sie nicht aus. Tabellenstatistiken werden nicht berechnet. Dieser Wert kann die Datendatei dauerhaft beschädigen. Nachdem Sie diesen Wert verwendet haben, müssen Sie alle sekundären Indizes löschen und neu erstellen. Stellen Sie InnoDB in MySQL 5.6.15 auf schreibgeschützt ein.
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
Sehen Sie sich beim Starten der Datenbank nicht das Undo-Protokoll an: InnoDB betrachtet sogar unvollständige Transaktionen als festgeschrieben. Dieser Wert kann die Datendatei dauerhaft beschädigen. Stellen Sie InnoDB in MySQL 5.6.15 auf schreibgeschützt ein.
6 (SRV_FORCE_NO_LOG_REDO)
Bei der Wiederherstellung wird kein Redo-Log-Rollforward durchgeführt. Dieser Wert kann die Datendatei dauerhaft beschädigen. Datenbankseiten in einem veralteten Zustand belassen, was wiederum zu weiteren Beschädigungen von B-Bäumen und anderen Datenbankstrukturen führen kann. Stellen Sie InnoDB in MySQL 5.6.15 auf schreibgeschützt ein.

Quelle: https://www.cnblogs.com/liucx/

Besuchen Sie die offizielle Website:
https://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_force_load_corrupted

Hoffe das hilft

Dies ist das Ende dieses Artikels zur Lösung des Problems, dass MySQL-Datenbanken unerwartet abstürzen, wodurch Tabellendatendateien beschädigt werden und nicht gestartet werden können. Weitere verwandte Lösungen zum Problem, dass MySQL-Datenbanken unerwartet abstürzen, wodurch Tabellendatendateien beschädigt werden und nicht gestartet werden können, finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder durchsuchen Sie die verwandten Artikel weiter unten. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!