Eine kurze Analyse der Unterschiede zwischen Undo, Redo und Binlog in MySQL

Vorwort

Es gibt sechs Arten von Protokolldateien in MySQL: Redo-Protokoll, Undo-Protokoll, Binärprotokoll, Fehlerprotokoll, Protokoll langsamer Abfragen, allgemeines Protokoll und Relay-Protokoll.

Unter ihnen sind Redo-Protokolle und Rollback-Protokolle eng mit Transaktionsvorgängen verbunden, und Binärprotokolle haben auch eine gewisse Beziehung zu Transaktionsvorgängen. Diese drei Protokolle sind für das Verständnis von Transaktionsvorgängen in MySQL von großer Bedeutung.

【Protokoll rückgängig machen】

Generieren Sie vor dem Start der Transaktion ein Undo-Protokoll für die aktuelle Transaktionsversion (Tipps: Das Undo-Protokoll generiert auch ein Redo-Protokoll, um die Zuverlässigkeit des Undo-Protokolls sicherzustellen).

Nach dem Festschreiben einer Transaktion wird das Undo-Protokoll nicht sofort gelöscht, sondern zur Bereinigung in eine verknüpfte Liste eingefügt. Der Bereinigungsthread ermittelt, ob andere Transaktionen die Versionsinformationen vor der vorherigen Transaktion in der Tabelle im Undo-Segment verwenden, und entscheidet so, ob der Protokollspeicherplatz des Undo-Protokolls bereinigt werden kann.

Eines der vier Hauptmerkmale von Datenbanktransaktionen ist die Atomizität. Atomizität bedeutet im Speziellen, dass eine Reihe von Operationen in der Datenbank entweder vollständig erfolgreich sein oder vollständig fehlschlagen muss. Ein teilweiser Erfolg ist nicht möglich.

Tatsächlich wird die zugrunde liegende Atomarität durch das Undo-Log erreicht. Das Undo-Log zeichnet hauptsächlich die logischen Änderungen der Daten auf. Beispielsweise gibt es für eine INSERT-Anweisung ein entsprechendes DELETE-Undo-Log. Für jede UPDATE-Anweisung gibt es ein entsprechendes gegenüberliegendes UPDATE-Undo-Log. Auf diese Weise kann bei einem Fehler der Datenzustand vor der Transaktion zurückgesetzt werden. Die ursprünglichen Datensätze in der Benutzertabelle lauten beispielsweise wie folgt:

Beim Ausführen sql update user set name = 'xiaohong' where id = 1; ist das generierte Undo-Protokoll wahrscheinlich update user set name = 'xiaoming' where id = 1;

Gleichzeitig ist das Undo-Log auch der Schlüssel zur Implementierung von MVCC (Multi-Version Concurrency Control).

【Protokoll wiederholen】

Wie stellt MySQL die Persistenz von Transaktionen sicher? Der einfachste Ansatz besteht darin, bei jedem Festschreiben der Transaktion alle geänderten Datenseiten, die an der Transaktion beteiligt sind, auf die Festplatte zu aktualisieren. Dies führt jedoch zu schwerwiegenden Leistungsproblemen, hauptsächlich in zweierlei Hinsicht:

• Da Innodb seitenweise mit der Festplatte interagiert und eine Transaktion möglicherweise nur wenige Bytes einer Datenseite ändert, wäre es eine Verschwendung von Ressourcen, jetzt die gesamte Datenseite auf die Festplatte zu schreiben!
• Eine Transaktion kann die Änderung mehrerer Datenseiten beinhalten, und diese Datenseiten sind physisch nicht kontinuierlich, sodass die Leistung bei der Verwendung von zufälligen IO-Schreibvorgängen zu schlecht ist!

Aus diesem Grund hat MySQL einen Redo-Log-Mechanismus entwickelt und die Leistung durch die WAL-Technologie (Write-Ahead Logging) optimiert. Der Kern von WAL besteht darin, zuerst Protokollfestplatten durch sequentielles IO zu beschreiben und dann Datenfestplatten durch zufälliges IO zu beschreiben, wodurch der IO-Verbrauch durch zufälliges Schreiben auf die Festplatte eingespart wird. Jedes Mal, wenn MySQL eine DML-Anweisung ausführt, hängt es die Datensätze zunächst der Reihe nach an den Redo-Log-Puffer an und aktualisiert die Daten im Speicher. Anschließend schreibt es die Datensätze stapelweise auf die Festplatte, damit sie dauerhaft gespeichert bleiben, wenn es inaktive Threads gibt, nicht genügend Speicher vorhanden ist oder das Redo-Log voll ist.

【Binärlog】

Binlog ist das logische Protokoll von MySQL und wird von der Serverebene aufgezeichnet. Es zeichnet die Informationen zu Schreibvorgängen (außer Abfragen) aller Datenbankmodule auf und wird in binärer Form auf der Festplatte gespeichert.

In praktischen Anwendungen wird Binlog hauptsächlich in zwei Szenarien verwendet: Master-Slave-Replikation und Datenwiederherstellung.

• Master-Slave-Replikation: Öffnen Sie das Binlog auf der Master-Seite und senden Sie dann das Binlog an jede Slave-Seite. Die Slave-Seite spielt das Binlog erneut ab, um eine Master-Slave-Datenkonsistenz zu erreichen.
• Datenwiederherstellung: Stellen Sie Daten mithilfe des Tools mysqlbinlog wieder her.

Wie können wir die Persistenz und Atomizität der Transaktion sicherstellen, wenn während des Datenaktualisierungsprozesses ein Systemausfall auftritt und ein abnormaler Neustart auftritt? Hier eine Übersicht:

1. Notieren Sie den Snapshot-Standort des Datensatzes vor diesem Update (dh schreiben Sie ein Undo-Protokoll).
2. Lesen Sie die für dieses Update benötigten Daten in den Speicher
3. Daten im Speicher aktualisieren (hohe Effizienz)
4. Schreiben Sie das Redo-Log und setzen Sie den Redo-Log-Status zur Vorbereitung
5. Binlog schreiben
6. Setzen Sie den Redo-Log-Status auf „Commit“.

Basierend auf dem oben vereinfachten Undo-Log-, Redo-Log- und Binlog-Schreibprozess wollen wir die Zuverlässigkeitsgarantien für Atomizität, Persistenz und Konsistenz klären:

A) Wenn bei einem der Schritte 1/2/3 ein Fehler auftritt, wird nach der Wiederherstellung festgestellt, dass im Redo-Protokoll kein unvollendeter Datensatz vorhanden ist. Nach der Wiederherstellung müssen Sie nur das Undo-Protokoll zurücksetzen, um die Szene wiederherzustellen.

B) Wenn in einem der Schritte 4 oder 5 ein Fehler auftritt und sich das Redo-Protokoll nach der Fehlerbehebung im Vorbereitungszustand befindet, ermitteln Sie weiter, ob es in das Binärprotokoll geschrieben wurde:

1. Wenn die Daten in das Binärprotokoll geschrieben wurden, führen Sie die entsprechenden Datensätze des Redo-Protokolls erneut aus, bis der Commit-Status erfolgreich erreicht ist (Master-Slave-Konsistenz).
2. Wenn das Binärprotokoll nicht geschrieben wird, führen Sie ein Rollback des Undo-Protokolls durch, um die Szene wiederherzustellen (Atomizität).
   

C) Wenn in Schritt 6 ein Fehler auftritt, befindet sich das Redo-Protokoll nach der Wiederherstellung im festgeschriebenen Zustand, was darauf hinweist, dass der Vorgang normal abgeschlossen wurde und nichts getan werden muss.

Zusammenfassen

Dies ist das Ende dieses Artikels über den Unterschied zwischen Rückgängigmachen, Wiederherstellen und Binärprotokoll in MySQL. Weitere Informationen zum Unterschied zwischen Rückgängigmachen, Wiederherstellen und Binärprotokoll in MySQL 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!