Analyse der MySQL-Absturzwiederherstellung basierend auf Redo Log und Undo Log

MySQL-Absturzwiederherstellungsprozess

Der Pufferpool ist eine Kernkomponente der MySQL-Speicherstruktur. Sie können ihn sich wie eine Blackbox vorstellen.

1. Datenfluss unter Blackbox aktualisieren

Wenn wir Daten abfragen, führen wir zuerst eine Abfrage im Pufferpool durch. Wenn die Daten nicht im Pufferpool vorhanden sind, lädt die Speicher-Engine die Daten zuerst von der Festplatte in den Pufferpool und gibt sie dann an den Client zurück. Wenn wir bestimmte Daten aktualisieren und die Daten nicht im Pufferpool vorhanden sind, werden sie ebenfalls zuerst geladen und dann im Speicher geändert. Die geänderten Daten werden später auf die Festplatte geschrieben.

Wiederherstellung nach MySQL-Absturz:

Dieses Verfahren scheint zwar in Ordnung zu sein, ist aber in Wirklichkeit unethisch. Angenommen, wir können die Daten im Pufferpool erfolgreich ändern, aber MySQL stürzt ab, bevor wir die Daten auf die Festplatte übertragen können. Was sollen wir tun? Gemäß der Logik in der obigen Abbildung sind die aktualisierten Daten nur im Pufferpool vorhanden. Wenn MySQL zu diesem Zeitpunkt abstürzt, geht dieser Teil der Daten dauerhaft verloren.

Und was muss ich tun, wenn mitten im Update plötzlich ein Fehler auftritt und ich zur Version vor dem Update zurückkehren möchte? Das ist ein Durcheinander. Wie können wir über eine Wiederherstellung nach einem Systemabsturz sprechen, wenn wir nicht einmal Datenpersistenz und Transaktions-Rollback garantieren können?

2. Redo-Log & Undo-Log

Und angesichts der Tatsache, dass MySQL nach einem Absturz wiederhergestellt werden kann, muss MySQL etwas Ausgefallenes getan haben. Das ist richtig, dies sind die beiden anderen wichtigen Funktionen, die wir als nächstes vorstellen werden: Redo Log und Undo Log .

Diese beiden Protokolle gehören zu den Protokollen der InnoDB-Speicher-Engine und haben nicht dieselbe Dimension wie das Binlog des MySQL-Servers.

(1) Das Redo-Protokoll zeichnet den Datenstatus nach Abschluss der Transaktion auf und zeichnet den Wert nach der Aktualisierung auf. (2) Das Undo-Protokoll zeichnet den Datenstatus vor Beginn der Transaktion auf und zeichnet den Wert vor der Aktualisierung auf. Es besteht also ein klarer Unterschied zwischen diesen beiden Protokolltypen. Ich werde diese beiden Protokolltypen anhand eines allgemeineren Beispiels erklären.

Redo Log ist so, als ob Sie einen langen Befehl in die Befehlszeile eingegeben, die Eingabetaste gedrückt hätten, um ihn auszuführen, und dann eine Fehlermeldung erhalten hätten. An diesem Punkt müssen wir nur erneut ↑ eingeben, um den vorherigen Befehl abzurufen und erneut auszuführen.

Undo Log ist so, als ob Sie gerade etwas in Git festgeschrieben und dann eine kompliziertere Änderung vorgenommen hätten, dann aber beim Vornehmen der Änderungen den Verstand verloren hätten und die gerade vorgenommenen Änderungen nicht mehr wollten, sodass Sie direkt mit git reset --hard $lastCommitId zur vorherigen Version zurückkehren.

3. Update-Prozess nach Implementierung des Protokolls

Verbessern wir das obige Bild mit Redo Log und Undo Log.

Wiederherstellung nach MySQL-Absturz:

Zunächst wird beim Aktualisieren von Daten noch geprüft, ob die Daten im Pufferpool vorhanden sind. Wenn nicht, werden sie geladen. Wir haben das Rollback-Problem oben erwähnt. Bevor wir die Daten im Pufferpool aktualisieren, müssen wir den Status der Daten vor Beginn der Transaktion in das Undo-Protokoll schreiben. Wenn während der Aktualisierung ein Fehler auftritt, können wir mithilfe des Undo-Logs zum Beginn der Transaktion zurückkehren.

Anschließend aktualisiert der Executor die Daten im Pufferpool und schreibt nach einer erfolgreichen Aktualisierung den neuesten Stand der Daten in den Redo-Log-Puffer. Da eine Transaktion mehrere Lese- und Schreibvorgänge umfassen kann, ist das gruppenweise Schreiben in den Puffer viel effizienter als das Schreiben einzelner Dateien in die Dateien auf der Festplatte.

Redo-Log-Puffer:

Warum verfügt Undo Log dann nicht auch über einen Undo Log-Puffer, um Undo Log zu beschleunigen, sodass beide davon profitieren können? Nehmen wir an, dass in InnoDB ein Puffer vorhanden ist, schreiben Sie den Datenstatus vor Beginn der Transaktion in den Undo-Log-Puffer und beginnen Sie dann mit der Aktualisierung der Daten.

Plötzlich, sehr schnell, wird MySQL aufgrund eines unerwarteten Prozesses beendet. In diesem Moment passiert etwas Peinliches. Wenn ein Teil der aktualisierten Daten auf die Festplatte zurückgeschrieben wurde, die Transaktion jedoch nicht erfolgreich war und zurückgesetzt werden muss, werden Sie feststellen, dass das Undo-Protokoll mit dem Prozessende verschwunden ist. Zu diesem Zeitpunkt gibt es keine Möglichkeit, über das Undo-Protokoll zurückzusetzen.

Was passiert, wenn MySQL direkt nach der Speicheraktualisierung abstürzt? Zu diesem Zeitpunkt ist der Redo-Log-Puffer möglicherweise noch nicht einmal geschrieben. Selbst wenn er geschrieben wird, wird er nicht auf die Festplatte geschrieben und das Redo-Log geht verloren.

Tatsächlich spielt es keine Rolle. Aufgrund der unerwarteten Ausfallzeit war die Transaktion nicht erfolgreich. Da die Transaktion nicht erfolgreich war, muss sie zurückgesetzt werden. Nach dem Neustart von MySQL wird die Redo-Log-Datei auf der Festplatte gelesen und ihr Status in den Pufferpool geladen. Der über die Redo-Log-Datei der Festplatte wiederhergestellte Zustand ist derselbe wie der Zustand vor dem Start der Transaktion vor der Ausfallzeit. Es gibt also keine Auswirkungen. Nachdem auf die Bestätigung der Transaktion gewartet wurde, werden das Redo-Protokoll und das Binärprotokoll auf die Festplatte geschrieben.

3. Probleme, die im Prozess noch bestehen

Sie denken vielleicht, das wäre perfekt, aber das ist nicht der Fall. Angenommen, MySQL stürzt plötzlich ab, nachdem wir das Redo-Protokoll auf die Festplatte geschrieben haben, und das Binärprotokoll nicht rechtzeitig geschrieben wurde. Wenn das System zu diesem Zeitpunkt neu gestartet wird, stimmt der durch das Redo-Protokoll dargestellte Status nicht mit dem durch das Binärprotokoll dargestellten Status überein. Das A-Feld einer Zeile, die durch das Redo-Protokoll in den Pufferpool wiederhergestellt wird, hat den Wert 3, aber die von einer Datenbank, die ihr Binärprotokoll überwacht, ausgelesenen Daten haben den Wert 2.

Auch wenn sowohl das Redo-Protokoll als auch das Binlog in Dateien geschrieben werden, gehen die Protokolle dennoch verloren, wenn die physische Maschine oder VM, auf der sich MySQL befindet, abstürzt. Wenn Sie eine Datei schreiben, schreibt das aktuelle Betriebssystem den geänderten Inhalt zuerst in den Betriebssystem-Cache, um die Effizienz zu verbessern. Anschließend werden die Daten im Betriebssystem-Cache basierend auf der Richtlinie (beeinflusst durch die von Ihnen konfigurierten Parameter) auf die Festplatte geschrieben.

4. Konsistenzgarantie basierend auf 2PC

Daraus lässt sich ein wesentliches Problem erkennen: Die Datenkonsistenz von Redo Log und Binlog muss beim Commit der Transaktion gewährleistet sein. Entweder sind beide vorhanden oder keines von beiden. MySQL wird durch **2PC (Two-Phase Commit Protocol)** implementiert.

Wiederherstellung nach MySQL-Absturz:

Lassen Sie mich kurz 2PC vorstellen, ein Protokoll, das die Konsistenz verteilter Transaktionsdaten sicherstellt. Sein chinesischer Name lautet Two-Phase Commit, das die Übermittlung verteilter Transaktionen in zwei Phasen aufteilt, nämlich Prepare und Commit/Rollback.

Genau wie vor dem Beginn eines Kampfes zwischen zwei Boxern bestätigt der Schiedsrichter den Status der beiden Kämpfer in der Mitte, ähnlich der Frage „Sind Sie bereit?“ Nach der Bestätigung sagt der Schiedsrichter „Kampf“ .

Der Schiedsrichter fragt die Spieler nach ihrem Status, was第一階段Prepare entspricht. Nach einer positiven Antwort verkündet der Schiedsrichter den offiziellen Spielbeginn, was第二階段Commit entspricht. Wenn jedoch ein Spieler nicht bereit ist, verkündet der Schiedsrichter eine Spielpause, was dem Scheitern der ersten Phase entspricht, und der Status der zweiten Phase ändert sich zu Rollback . Der Schiedsrichter entspricht協調者Coordinator im 2PC und der Spieler entspricht參與者Participant .

Schauen wir uns den gesamten Vorgang anhand eines Bildes an: 2PC Flash auf Festplatte

In der Vorbereitungsphase wird das Redo-Protokoll in eine Datei geschrieben und auf die Festplatte geleert, die ID der internen XA-Transaktion wird aufgezeichnet und der Status des Redo-Protokolls wird auf „Vorbereiten“ gesetzt. Nachdem das Redo-Protokoll erfolgreich geschrieben wurde, wird auch das Binärprotokoll auf die Festplatte geschrieben, um die XA-Transaktions-ID aufzuzeichnen.

In der Commit-Phase wird das Commit-Flag in das Redo-Log auf der Festplatte geschrieben, um anzuzeigen, dass die Transaktion festgeschrieben wurde. Der Executor ruft dann die Schnittstelle der Speicher-Engine auf, um die Transaktion festzuschreiben. Das ist der gesamte Prozess.

5. Überprüfen Sie die Verfügbarkeit des 2PC-Mechanismus

Dies ist der Prozess, bei dem 2PC Redo Log und Binlog übermittelt. Wenn während dieser Zeit eine Ausnahme auftritt, kann der 2PC-Mechanismus dann wirklich die Datenkonsistenz garantieren?

Angenommen, das Redo-Protokoll wurde erfolgreich geleert, MySQL stürzt jedoch ab, bevor es das Binärprotokoll leeren kann. Nach dem Neustart werden Sie feststellen, dass das Redo-Protokoll keinen Commit-Marker enthält. Suchen Sie zu diesem Zeitpunkt diese Transaktion basierend auf der aufgezeichneten XA-Transaktion und führen Sie einen Rollback durch.

Wenn das Redo-Protokoll erfolgreich geleert wurde und das Binärprotokoll ebenfalls erfolgreich geleert wurde, MySQL jedoch abstürzt, bevor Sie das Redo-Protokoll von „Vorbereiten“ auf „Commit“ ändern können, werden Sie beim Neustart feststellen, dass das von XID abgefragte Binärprotokoll erfolgreich auf die Festplatte geleert wurde, obwohl das Redo-Protokoll kein Commit-Flag aufweist.

Obwohl zu diesem Zeitpunkt keine Commit-Markierung im Redo-Protokoll vorhanden ist, muss MySQL die Transaktion dennoch festschreiben. Denn sobald das Binlog geschrieben ist, kann es vom Slave oder jedem anderen Verbraucher verwendet werden, der das Binlog verwendet. Wenn MySQL die Transaktion zu diesem Zeitpunkt nicht festschreibt, kann es zu Dateninkonsistenzen kommen. Darüber hinaus stehen Redo Log und Binlog bis auf ein Flag tatsächlich auf Datenebene zur Verfügung.

Damit ist dieser Artikel über die MySQL-Absturzwiederherstellungsanalyse basierend auf Redo Log und Undo Log abgeschlossen. Weitere Informationen zum MySQL-Absturzwiederherstellungsprozess finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!