Analyse von Redo und Undo in MySQL-Transaktionen (Bild und Text)

Der Inhalt dieses Artikels befasst sich mit der Analyse (Bilder und Texte) von Redo und Undo in MySQL. Ich hoffe, dass er für Sie hilfreich ist.

Wir alle wissen, dass Transaktionen vier Merkmale aufweisen: Atomizität, Konsistenz, Isolation und Dauerhaftigkeit. Alle Vorgänge in einer Transaktion werden entweder ausgeführt oder überhaupt nicht ausgeführt. Die Isolierung von Transaktionen wird durch den Sperrmechanismus erreicht, und die Atomizität, Konsistenz und Haltbarkeit werden durch das Redo-Log und das Undo-Log der Transaktion garantiert. In diesem Artikel werden daher verschiedene Fragen zum Wiederherstellen und Rückgängigmachen bei Transaktionen behandelt:

• Was sind Redo-Logs und Undo-Logs?

• Wie stellt Redo die Haltbarkeit von Transaktionen sicher?

• Ist das Undo-Log der umgekehrte Prozess des Redo-Logs?

Redo-Log

Art des Redo

Redo-Log wird verwendet. Garantieren Sie die Haltbarkeit des Transaktion, die das D in der Transaktions-ACID ist. Tatsächlich kann es in die folgenden zwei Typen unterteilt werden:

• Physisches Redo-Protokoll

• Logisches Redo-Protokoll

In der InnoDB-Speicher-Engine ist Redo in den meisten Fällen ein physisches Protokoll, das die physischen Änderungen der Datenseite aufzeichnet . Das logische Redo-Protokoll zeichnet nicht die tatsächliche Änderung der Seite auf, sondern zeichnet einen Vorgangstyp auf, der die Seite ändert. Wenn beispielsweise eine neue Datenseite erstellt wird, muss ein logisches Protokoll aufgezeichnet werden. In Bezug auf das logische Redo-Protokoll handelt es sich um Inhalte auf niedrigerer Ebene. Hier müssen wir uns nur daran erinnern, dass Redo in den meisten Fällen ein physisches Protokoll ist, das Redo aufzeichnen muss.

Die Rolle von Redo

Die Hauptfunktion des Redo-Protokolls ist die Wiederherstellung nach einem Datenbankabsturz.

Die Zusammensetzung von Redo

Das Redo-Protokoll kann einfach in die folgenden zwei Teile unterteilt werden:

• Der erste ist der Redo-Log-Puffer im Speicher, der flüchtig ist.

• Der zweite ist die Redo-Log-Datei und wird auf der Festplatte gespeichert

Wann soll Redo geschrieben werden?

Das obige Bild spiegelt lediglich den Schreibprozess von Redo wider Schreiben von Redo:

• Nachdem die Änderung der Datenseite abgeschlossen ist und bevor die schmutzige Seite von der Festplatte gelöscht wird, wird das Redo-Protokoll geschrieben. Beachten Sie, dass zuerst die Daten geändert werden, dann wird das Protokoll geschrieben

• das Redo-Protokoll wird vor der Datenseite auf die Festplatte zurückgeschrieben

• Aggregation Änderungen an Indizes, sekundären Indizes und Rückgängig-Seiten müssen alle in Redo-Protokollen aufgezeichnet werden.

Der Gesamtprozess von Redo

Im Folgenden wird eine Aktualisierungstransaktion als Beispiel genommen, um den Redo-Log-Flussprozess aus einer Makroperspektive zu erfassen, wie in der folgenden Abbildung dargestellt :

• Schritt 1: Lesen Sie zuerst die Originaldaten von der Festplatte in den Speicher und ändern Sie die Speicherkopie des Daten

• Schritt 2: Erzeugen Sie ein Redo-Log und schreiben Sie es in den Redo-Log-Puffer, der den geänderten Wert der Daten aufzeichnet

• Schritt 3: Wenn die Transaktion festgeschrieben ist, aktualisieren Sie den Inhalt des Redo-Log-Puffers in der Redo-Log-Datei und verwenden Sie „Append Writing“ in die Redo-Log-Datei.

• Schritt 4: Aktualisieren Sie die Änderungen regelmäßig Daten im Speicher auf die Festplatte übertragen

Wie stellt Redo die Haltbarkeit von Transaktionen sicher?

InnoDB ist eine Transaktionsspeicher-Engine. Sie erreicht die Haltbarkeit von Transaktionen durch den Force Log at Commit-Mechanismus, d. h. wenn eine Transaktion festgeschrieben wird, wird zuerst der Redo-Log-Puffer in den Redo-Speicher geschrieben Die Persistenz der Protokolldatei wird erst abgeschlossen, wenn der Commit-Vorgang der Transaktion abgeschlossen ist. Dieser Ansatz wird auch als Write-Ahead-Protokoll (Pre-Log-Persistenz) bezeichnet. Vor dem Persistieren einer Datenseite wird die entsprechende Protokollseite im Speicher gespeichert.

Um sicherzustellen, dass jedes Protokoll in die Redo-Log-Datei geschrieben wird, muss die InnoDB-Speicher-Engine nach jedem Schreiben des Redo-Puffers in die Redo-Log-Datei standardmäßig einen fsync aufrufen Operation ,Da das Redo-Log ohne die Option O_DIRECT geöffnet wird, wird das Redo-Log zunächst in den Dateisystem-Cache geschrieben. Um sicherzustellen, dass das Redo-Log auf die Festplatte geschrieben wird, muss ein fsync-Vorgang ausgeführt werden. fsync ist eine Systemaufrufoperation. Die Effizienz von fsync hängt von der Leistung der Festplatte ab. Daher wirkt sich die Leistung der Festplatte auch auf die Leistung der Transaktionsübermittlung aus.
(Die Option O_DIRECT ist eine Option im Linux-System. Nach Verwendung dieser Option wird die Datei direkt per E/A bedient und direkt auf die Festplatte geschrieben, ohne den Dateisystem-Cache zu durchlaufen)

Der oben erwähnte Force Log at Commit-Mechanismus wird durch den Parameter innodb_flush_log_at_trx_commit gesteuert, der von der InnoDB-Speicher-Engine bereitgestellt wird. Dieser Parameter kann die Strategie des Redo-Log-Leerens auf die Festplatte steuern Erlauben Sie Benutzern auch, Folgendes festzulegen:

• Wenn der Parameter auf 1 gesetzt ist (der Standardwert ist 1), bedeutet dies, dass der fsync-Vorgang ausgeführt werden muss Wird einmal aufgerufen, wenn die Transaktion festgeschrieben wird. Dies ist die sicherste Konfiguration, um die Haltbarkeit sicherzustellen

• Wenn der Parameter auf 2 gesetzt ist, wird beim Senden der Transaktion nur der Vorgang Schreiben ausgeführt, wodurch nur sichergestellt wird, dass der Redo-Log-Puffer in den Seitencache des Systems geschrieben wird , und es wird kein fsync-Vorgang ausgeführt. Wenn also die MySQL-Datenbank ausfällt, geht die Transaktion nicht verloren, aber das Betriebssystem kann ausfallen.

• Wenn der Parameter auf gesetzt ist 0 bedeutet, dass beim Senden der Transaktion kein Redo-Vorgang geschrieben wird. Dieser Vorgang wird nur im Master-Thread abgeschlossen und der Fsync-Vorgang des Redo-Protokolls wird alle 1 Sekunde im Master-Thread ausgeführt, sodass die Instanz abstürzt wird Transaktionen innerhalb von höchstens 1 Sekunde verlieren. (Der Master-Thread ist für die asynchrone Aktualisierung der Daten im Pufferpool auf der Festplatte verantwortlich, um die Datenkonsistenz sicherzustellen.)

fsync und write Operationen sind eigentlich Systemaufruffunktionen wird in vielen Persistenzszenarien verwendet. Beispielsweise werden zwei Funktionen auch in der AOF-Persistenz von Redis verwendet. Der fsync-Vorgang sendet die Daten an die Festplatte, erzwingt die Festplattensynchronisierung und blockiert, bis das Schreiben auf die Festplatte abgeschlossen ist und zurückkehrt. Das Ausführen einer großen Anzahl von fsync-Vorgängen führt zu einem Leistungsengpass write Der Vorgang schreibt die Daten sofort in den Seitencache des Systems und verlässt sich dann auf den Planungsmechanismus des Systems, um die zwischengespeicherten Daten auf die Festplatte zu leeren. Die Reihenfolge lautet Benutzerpuffer——>Seitencache—>Festplatte.

Zusätzlich zum oben erwähnten Force Log at Commit-Mechanismus zur Gewährleistung der Haltbarkeit von Transaktionen hängt tatsächlich auch die Implementierung des Redo-Logs davon ab für Mini-Transaktionen aktiviert.

Wie wird Redo in InnoDB implementiert? Verbindung zur Mini-Transaktion?

Die Implementierung von Redo ist tatsächlich eng mit der Minitransaktion verbunden. Minitransaktionen werden intern von InnoDB verwendet, um die Daten auf der Datenseite während gleichzeitiger Transaktionsvorgänge sicherzustellen und wenn die Datenbank abnormal ist , aber nicht Teil der Transaktion ist.

Damit die Mini-Transaktion die Konsistenz der Datenseitendaten gewährleistet, muss die Mini-Transaktion den folgenden drei Protokollen folgen :

• Die FIX-Regeln

• Write-Ahead-Protokoll

• Force-log-at-commit

Die FIX-Regeln

Beim Ändern einer Datenseite müssen Sie den X-Latch (exklusive Sperre) der Seite erhalten. Beim Erwerb einer Datenseite benötigen Sie den S-Latch (lesen). Sperre oder gemeinsame Sperre) der Seite) oder x-Latch, der die Sperre auf der Seite hält, bis der Vorgang zum Ändern oder Zugreifen auf die Seite abgeschlossen ist.

Write-Ahead-Protokoll

Write-Ahead-Protokoll wurde in der vorherigen Erklärung erwähnt. Bevor eine Datenseite beibehalten wird, muss zunächst die entsprechende Protokollseite im Speicher beibehalten werden. Jede Seite verfügt über eine LSN (Protokollsequenznummer), die die Protokollsequenznummer darstellt (LSN belegt 8 Bytes und nimmt monoton zu). Wenn eine Datenseite auf ein persistentes Gerät geschrieben werden muss, ist weniger als die LSN der Seite erforderlich im Speicher. Das Protokoll wird zuerst auf das Persistenzgerät geschrieben

Warum müssen wir also zuerst das Protokoll schreiben? Ist es möglich, Daten direkt auf die Festplatte zu schreiben, ohne Protokolle zu schreiben? Im Prinzip ist dies möglich, führt jedoch zu einigen Problemen. Bei der Datenänderung werden zufällige E/A-Vorgänge generiert. Die Append-Methode schreibt jedoch sequentiell, was eine serielle Methode darstellt, sodass die Leistung der Festplatte voll ausgeschöpft werden kann genutzt.

Force-log-at-commit

Dies ist der Inhalt, wie die oben erwähnte Haltbarkeit der Transaktionen sichergestellt werden kann Inhalt entspricht. In einer Transaktion können mehrere Seiten geändert werden. Das Write-Ahead-Protokoll kann die Konsistenz einer einzelnen Datenseite sicherstellen, kann jedoch nicht die Dauerhaftigkeit der Transaktion garantieren, wenn eine Transaktion festgeschrieben wird mini - Das Transaktionsprotokoll muss auf die Festplatte geleert werden. Wenn die Datenbank nach Abschluss der Protokollleerung abstürzt, bevor die Seiten im Pufferpool auf das persistente Speichergerät geleert werden, kann die Integrität der Daten beeinträchtigt werden durch das Protokoll sichergestellt werden.

Redo-Log-Schreibprozess

Die obige Abbildung zeigt den Schreibprozess des Redo-Log-Prozesses, jeden Mini -Transaktion entspricht jeder DML-Operation, beispielsweise einer Aktualisierungsanweisung, die durch eine Minitransaktion garantiert wird. Nach der Änderung der Daten wird redo1 generiert, das zunächst in den privaten Puffer der Minitransaktion geschrieben wird, und die Aktualisierung erfolgt Anweisung Kopieren Sie nach Abschluss redo1 vom privaten Puffer in den öffentlichen Protokollpuffer. Wenn die gesamte externe Transaktion festgeschrieben ist, wird der Redo-Log-Puffer in die Redo-Log-Datei geleert.

Rückgängig-Protokoll

Definition des Rückgängig-Protokolls

Das Rückgängig-Protokoll zeichnet hauptsächlich die logischen Änderungen von Daten auf, um To Wenn ein Fehler auftritt, führen Sie einen Rollback des vorherigen Vorgangs durch. Sie müssen alle vorherigen Vorgänge aufzeichnen und dann einen Rollback durchführen, wenn ein Fehler auftritt.

Die Rolle des Rückgängig-Protokolls

Rückgängig ist ein logisches Protokoll, das zwei Funktionen hat:

• Für Transaktions-Rollback

• MVCC

Ich werde hier nicht viel über MVCC (Multi-Version Concurrency Control) sagen. Dieser Artikel konzentriert sich auf das Rückgängig-Protokoll für das Transaktions-Rollback.

Das Rückgängigmachen des Protokolls stellt die Datenbank nur logisch in ihrem ursprünglichen Zustand wieder her. Während des Rollbacks wird tatsächlich das Gegenteil ausgeführt. Beispielsweise entspricht ein INSERT einem DELETE, und für jedes UPDATE entspricht es einem umgekehrten UPDATE Zurücksetzen der Zeile vor der Änderung. Das Rückgängig-Protokoll wird für Transaktions-Rollback-Vorgänge verwendet, um die Atomizität der Transaktion sicherzustellen.

Zeitpunkt für das Schreiben des Rückgängig-Protokolls

• Bevor der DML-Vorgang den Clustered-Index ändert, zeichnen Sie das Rückgängig-Protokoll auf

• Änderungen an sekundären Indexdatensätzen zeichnen keine Undo-Logs auf

Es ist zu beachten, dass bei Änderungen an Undo-Seiten auch Redo-Logs aufgezeichnet werden müssen.

Der Speicherort von Undo

In der InnoDB-Speicher-Engine wird Undo im Rollback-Segment (Rollback) gespeichert Segment) zeichnet jedes Rollback-Segment 1024 Rückgängig-Protokollsegmente auf, und das Rückgängigmachen wird in jedem Rückgängig-Protokollsegment durchgeführt. Um eine Seite zu beantragen, befand sich vor 5.6 das Rollback-Segment im gemeinsam genutzten Tabellenbereich. Nach 5.6.3 können Sie es verwenden innodb_undo_tablespace legt den Speicherort für das Rückgängigmachen fest.

Art des Rückgängigmachens

In der InnoDB-Speicher-Engine ist das Rückgängig-Protokoll unterteilt in:

• Rückgängig-Protokoll einfügen

• Rückgängig-Protokoll aktualisieren

Rückgängig-Protokoll einfügen bezieht sich auf das während des Einfügevorgangs generierte Rückgängig-Protokoll, da der Datensatz des Einfügevorgangs nur für sichtbar ist Die Transaktion selbst ist für andere Transaktionen unsichtbar. Daher kann das Rückgängig-Protokoll direkt nach der Übermittlung der Transaktion gelöscht werden und es ist kein Löschvorgang erforderlich.

Das Update-Rückgängig-Protokoll zeichnet das durch Lösch- und Aktualisierungsvorgänge generierte Rückgängig-Protokoll auf. Das Rückgängig-Protokoll muss möglicherweise einen MVCC-Mechanismus bereitstellen, sodass es nicht gelöscht werden kann, wenn die Transaktion festgeschrieben wird. Fügen Sie es beim Senden in die Rückgängig-Protokollliste ein und warten Sie, bis der Bereinigungsthread den endgültigen Löschvorgang durchführt.

Ergänzung: Die beiden Hauptfunktionen des Bereinigungsthreads sind: Bereinigen der Rückgängig-Seite und Löschen der Datenzeilen mit dem Flag „Delete_Bit“ auf der Seite. In InnoDB löscht die Löschoperation in einer Transaktion nicht tatsächlich die Datenzeile, sondern eine Löschmarkierungsoperation, die das Delete_Bit im Datensatz markiert, ohne den Datensatz zu löschen. Es handelt sich um eine Art „falsche Löschung“, die nur markiert wird. Die eigentliche Löscharbeit muss vom Hintergrundbereinigungsthread abgeschlossen werden.

Ist das Undo-Log der umgekehrte Prozess des Redo-Logs?

Ist das Rückgängigmachen des Protokolls erneut möglich? Der umgekehrte Prozess des Protokolls? Tatsächlich kann die Antwort aus dem vorherigen Artikel abgeleitet werden. Beim Zurücksetzen einer Transaktion wird die Datenbank nur logisch auf ihren ursprünglichen Zustand zurückgesetzt Das Protokoll ist ein physisches Protokoll, das die physischen Änderungen der Datenseiten aufzeichnet. Offensichtlich ist das Rückgängig-Protokoll nicht der umgekehrte Vorgang des Redo-Protokolls.

Wiederherstellen und Rückgängigmachen-Zusammenfassung

Das Folgende ist der vereinfachte Prozess von Redo-Log + Undo-Log, um das Verständnis der beiden Protokollprozesse zu erleichtern:

假设有A、B两个数据，值分别为1,2.
1. 事务开始
2. 记录A=1到undo log
3. 修改A=3
4. 记录A=3到 redo log
5. 记录B=2到 undo log
6. 修改B=4
7. 记录B=4到redo log
8. 将redo log写入磁盘
9. 事务提交

Tatsächlich sind beim Einfüge-/Aktualisierungs-/Löschvorgang die durch Wiederherstellen und Rückgängigmachen aufgezeichneten Inhalte und Beträge unterschiedlich. Im InnoDB-Speicher lautet die allgemeine Reihenfolge wie folgt:

• Schreiben Sie Rückgängig und Wiederholen

• Schreiben Sie Rückgängig

• Datenseite ändern

• Write Redo

Zusammenfassung

Dieser Artikel analysiert die Transaktion Redo- und Undo-Protokolle werden unter Bezugnahme auf einige Informationsbücher zusammengestellt. Einige Stellen sind möglicherweise nicht klar. Wenn etwas nicht stimmt, weisen Sie es bitte darauf hin.

Das obige ist der detaillierte Inhalt vonAnalyse von Redo und Undo in MySQL-Transaktionen (Bild und Text). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!