Lösung zum automatischen Neustart von MySQL

Vorwort

Kürzlich trat in der Testumgebung ein Problem auf, bei dem die MySQL-Datenbank immer wieder automatisch neu gestartet wurde. Die Ursache war, dass der Datenbankprozess durch kill -9 zwangsweise beendet wurde. Die Fehlermeldung lautete:

2019-07-24T01:14:53.769512Z 0 [Hinweis] Ausführen von „SELECT * FROM INFORMATION_SCHEMA.TABLES;“, um eine Liste von Tabellen zu erhalten, die die veraltete Partitions-Engine verwenden. Sie können die Startoption „--disable-partition-engine-check“ verwenden, um diese Prüfung zu überspringen.
2019-07-24T01:14:53.769516Z 0 [Hinweis] Beginn der Liste nicht nativ partitionierter Tabellen
01:14:53 UTC – mysqld hat Signal 11 erhalten;
Dies könnte daran liegen, dass Sie auf einen Fehler gestoßen sind. Es ist auch möglich, dass diese Binärdatei
oder eine der Bibliotheken, mit denen es verknüpft war, ist beschädigt, falsch erstellt,
oder falsch konfiguriert. Dieser Fehler kann auch durch eine Fehlfunktion der Hardware verursacht werden.
Es wird versucht, Informationen zu sammeln, die bei der Diagnose des Problems hilfreich sein könnten.
Da es sich um einen Absturz handelt und definitiv etwas nicht stimmt, werden die Informationen
Der Erfassungsprozess könnte fehlschlagen.
Bitte helfen Sie uns, Percona Server zu verbessern, indem Sie
Fehler unter http://bugs.percona.com/

Schlüsselpuffergröße = 33554432
Puffergröße lesen=8388608
max_used_connections=0
max_threads=501
Threadanzahl = 4
Verbindungsanzahl = 0
Es ist möglich, dass mysqld bis zu
Schlüsselpuffergröße + (Lesepuffergröße + Sortierpuffergröße)*max_threads = 4478400 KB Speicher
Hoffe, das ist ok. Wenn nicht, verringern Sie einige Variablen in der Gleichung.

Thread-Zeiger: 0x7f486900e000
Backtrace wird versucht. Mit den folgenden Informationen können Sie herausfinden,
wo mysqld abgestürzt ist. Wenn Sie danach keine Nachrichten mehr sehen, ist etwas schiefgegangen
furchtbar falsch...
Stapel_unten = 7f4846172820 Thread_Stapel 0x80000
/usr/local/mysql5.7/bin/mysqld(my_print_stacktrace+0x2c)[0xed481c]
/usr/local/mysql5.7/bin/mysqld(handle_fatal_signal+0x461)[0x7a15a1]
/lib64/libpthread.so.0(+0xf7e0)[0x7f498697c7e0]
/usr/local/mysql5.7/bin/mysqld(_ZN12ha_federated7rnd_posEPhS0_+0x2f)[0x12bcc3f]
/usr/local/mysql5.7/bin/mysqld(_ZN7handler10ha_rnd_posEPhS0_+0x172)[0x804a12]
/usr/local/mysql5.7/bin/mysqld(_ZN14Rows_log_event24do_index_scan_and_updateEPK14Relay_log_info+0x1e3)[0xe50e23]
/usr/local/mysql5.7/bin/mysqld(_ZN14Rows_log_event14do_apply_eventEPK14Relay_log_info+0x716)[0xe50196]
/usr/local/mysql5.7/bin/mysqld(_ZN9Log_event11apply_eventEP14Relay_log_info+0x6e)[0xe48fde]
/usr/local/mysql5.7/bin/mysqld(_Z26apply_event_and_update_posPP9Log_eventP3THDP14Relay_log_info+0x1f0)[0xe8d6f0]
/usr/local/mysql5.7/bin/mysqld(handle_slave_sql+0x163d)[0xe9a0fd]
/usr/local/mysql5.7/bin/mysqld(pfs_spawn_thread+0x1b4)[0x1209414]
/lib64/libpthread.so.0(+0x7aa1)[0x7f4986974aa1]
/lib64/libc.so.6(Klon+0x6d)[0x7f4984c6bc4d]

Ich versuche, einige Variablen zu erhalten.
Einige Zeiger sind möglicherweise ungültig und führen zum Abbruch des Dumps.
Abfrage (0): ist ein ungültiger Zeiger
Verbindungs-ID (Thread-ID): 2
Status: NICHT BEENDET

Sie können das Percona Server-Betriebshandbuch hier herunterladen:
http://www.percona.com/software/percona-server/. Informationen dazu finden Sie unter
im Handbuch, die Ihnen dabei helfen, die Absturzursache zu ermitteln.

1. Erster Explorationsprozess

Als eine ähnliche Situation zuvor auftrat, lag es an nicht ausreichendem Speicher, da im Protokoll eine entsprechende Eingabeaufforderung angezeigt wurde:

Schlüsselpuffergröße = 33554432
Puffergröße lesen=8388608
max_used_connections=0
max_threads=501
Threadanzahl = 4
Verbindungsanzahl = 0
Es ist möglich, dass mysqld bis zu
Schlüsselpuffergröße + (Lesepuffergröße + Sortierpuffergröße)*max_threads = 4478400 KB Speicher
Hoffe, das ist ok. Wenn nicht, verringern Sie einige Variablen in der Gleichung.

Der physische Speicher dieser Testumgebung ist tatsächlich nicht groß und der verbleibende Speicher reicht nicht aus. Darüber hinaus handelt es sich um eine Slave-Bibliothek einer anderen Testumgebung, sodass auch die Speicherzuweisung gering ist.

Ähnliche Situationen sind in einigen Umgebungen schon einmal aufgetreten. Nach dem Anpassen der Parameter und dem Freigeben des Speichers kann das System normal gestartet werden. Daher habe ich versucht, einige temporäre Programme zu schließen und die Werte der oben genannten Parameter von MySQL anzupassen, beispielsweise:

[mysqld]
max_Verbindungen = 50

Starten Sie MySQL anschließend neu und der Neustart wird fortgesetzt.

Die erste Behandlung war erfolglos.

2. Fügen Sie innodb_force_recovery hinzu, um das Problem des kontinuierlichen Neustarts zu lösen

Fügen Sie innodb_force_recovery zur Konfigurationsdatei my.cnf hinzu, um zuerst das Problem kontinuierlicher Neustarts zu beheben

[mysqld]
innodb_force_recovery = 4

Starten Sie MySQL nach dem Hinzufügen erneut. Dann treten keine wiederholten Neustarts mehr auf.

Überprüfen Sie das Datenbankprotokoll. Es gibt eine Eingabeaufforderung [Hinweis] InnoDB: !!! innodb_force_recovery ist wie folgt auf 4 !!! eingestellt:

Da die Datenbank zu diesem Zeitpunkt geöffnet werden kann, versuche ich, die Slave-Bibliothek zu starten, es wird jedoch ein Fehler gemeldet, der darauf hinweist, dass die Tabelle „mysql.slave_relay_log_info“ schreibgeschützt ist.

Schauen Sie sich nun das Fehlerprotokoll wie folgt an

Daher wird innodb_force_recovery während dieses Starts auf 4 gesetzt. Nach MySQL 5.6.15 befindet sich die InnoDB-Tabelle im schreibgeschützten Modus, wenn der Wert von innodb_force_recovery größer oder gleich 4 ist. Da beim Starten der Replikation Informationen in die Tabelle geschrieben werden müssen, wird zu diesem Zeitpunkt ein Fehler gemeldet.

Hinweis: Da es bei den Einstellungen 1-3 immer noch nicht funktioniert, habe ich es bei der Verarbeitung auf 4 gesetzt (Werte über 4 können die Datendatei dauerhaft beschädigen. Wenn in der Produktionsumgebung ein ähnliches Problem auftritt, kopieren Sie unbedingt zuerst einen Test und verarbeiten Sie ihn nach Bestehen des Tests in der Produktionsumgebung). An diesem Punkt können Sie alle Daten sichern und später wiederherstellen.

3. innodb_force_recovery-Parameter

innodb_force_recovery kann auf 1-6 eingestellt werden, wobei größere Werte die Auswirkungen aller vorherigen Werte, die kleiner als dieser sind, einschließen.

1 (SRV_FORCE_IGNORE_CORRUPT): Erkannte beschädigte Seiten ignorieren. Erzwingen Sie die Ausführung des Dienstes, obwohl beschädigte Seiten erkannt wurden. Im Allgemeinen können Sie diesen Wert festlegen und dann die Tabelle sichern, um sie neu zu erstellen.

2 (SRV_FORCE_NO_BACKGROUND): Verhindert die Ausführung des Hauptthreads. Wenn der Hauptthread einen vollständigen Bereinigungsvorgang durchführen muss, führt dies zu einem Absturz. Verhindert die Ausführung des Master-Threads und aller Bereinigungs-Threads. Dieser Wert wird verwendet, wenn der Absturz während der Bereinigungsphase auftritt.

3 (SRV_FORCE_NO_TRX_UNDO): Führen Sie kein Transaktions-Rollback durch.

4 (SRV_FORCE_NO_IBUF_MERGE): Keine Zusammenführung des Insert-Pufferspeichers durchführen. Führen Sie diese Vorgänge nicht aus, wenn sie zu einem Absturz führen könnten. Führen Sie keine statistischen Operationen durch. Dieser Wert kann die Datendatei dauerhaft beschädigen. Wenn dieser Wert verwendet wird, muss der sekundäre Index gelöscht und später neu erstellt werden.

5 (SRV_FORCE_NO_UNDO_LOG_SCAN): Ohne in das Redo-Protokoll zu schauen, behandelt die InnoDB-Speicher-Engine nicht festgeschriebene Transaktionen als festgeschrieben. Derzeit behandelt InnoDB sogar nicht abgeschlossene Transaktionen als festgeschrieben. Dieser Wert kann die Datendatei dauerhaft beschädigen.

6 (SRV_FORCE_NO_LOG_REDO): Führen Sie keinen Rollforward-Vorgang durch. Während der Wiederherstellung wird kein Redo-Log-Rollforward durchgeführt. Dadurch werden Datenbankseiten in einen ungültigen Zustand versetzt, was zu weiteren Schäden an B-Bäumen oder anderen Datenbankstrukturen führen kann.

Beachten:

1. Wenn der Parameterwert auf einen Wert größer als 0 gesetzt ist, können aus Sicherheitsgründen Auswahl-, Erstellungs- und Löschvorgänge für die Tabelle ausgeführt werden, Einfüge-, Aktualisierungs- oder Löschvorgänge sind jedoch nicht zulässig.
2. Nach MySQL 5.6.15 befindet sich die InnoDB-Tabelle im schreibgeschützten Modus, wenn der Wert von innodb_force_recovery größer oder gleich 4 ist.
3. Wenn der Wert kleiner oder gleich 3 ist, können Sie die Tabelle sichern, indem Sie die Tabelle auswählen, löschen oder erstellen.
4. MySQL 5.6.27 und höher unterstützt DROP TABLE auch für Werte größer als 3; wenn Sie im Voraus wissen, welche Tabelle den Absturz verursacht hat, können Sie die Tabelle löschen.
5. Wenn aufgrund eines fehlgeschlagenen umfangreichen Imports oder einer großen Anzahl von ALTER TABLE-Vorgängen ein unkontrolliertes Rollback auftritt, können Sie den mysqld-Thread beenden und innodb_force_recovery = 3 festlegen, um ein Rollback der Datenbank nach dem Neustart zu verhindern. Löschen Sie dann die Tabelle, die den außer Kontrolle geratenen Rollback verursacht hat. Wenn die Daten in der Tabelle beschädigt sind, kann nicht der gesamte Tabelleninhalt gesichert werden. Dann könnte eine Abfrage mit einer Order-by-Primary_Key-Desc-Klausel einen Teil der Daten nach dem beschädigten Teil sichern.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.