Was ist das Konzept von MySQL-Redo-Logs?

Unter den ACID-Merkmalen von Transaktionen werden Atomizität (A), Konsistenz (C) und Haltbarkeit (D) durch Undo-Log und Redo-Log realisiert, und Isolation (I) wird durch Sperre + MVCC realisiert

Undo-Log: Transaktion noch Wenn es kein Commit gibt und während der Ausführung eine Ausnahme auftritt, können Sie das Rückgängig-Protokoll verwenden, um die Daten vor der Transaktionsausführung wiederherzustellen, um die Atomizität der Transaktion sicherzustellen.

Redo-Protokoll: Das Transaktions-Commit ist erfolgreich Es dauert eine Weile, bis die Festplattendaten aktualisiert sind. Wenn zu diesem Zeitpunkt eine Ausnahme auftritt, können Sie das Redo-Protokoll verwenden, um die SQL dieser Transaktion erneut auszuführen, um die Haltbarkeit der Transaktion sicherzustellen (Solange das Festschreiben der Transaktion erfolgreich ist, spielt es keine Rolle Welche ungewöhnlichen Ereignisse treten auf? Solange der MySQL-Dienst das nächste Mal normal ausgeführt wird, müssen die Daten des letzten Commits wiederhergestellt werden.

1 Das Konzept des Redo-Protokolls: Es wird als physisches Protokoll bezeichnet Die endgültigen geänderten Daten werden seitenweise gespeichert. Es speichert direkt den endgültigen Status der Daten und wird verwendet, um die Haltbarkeit von Transaktionen sicherzustellen.

Das logische Protokoll wird auch als Rückgängig-Protokoll bezeichnet und zeichnet den spezifischen Inhalt der entsprechenden SQL-Anweisung auf. Wenn das Einfügen jetzt ausgeführt wird, wird beim Zurücksetzen das Löschen ausgeführt. Wenn das Update jetzt ausgeführt wird, wird der ursprüngliche alte Wert erneut aktualisiert. Das Redo-Protokoll wird standardmäßig unter

platziert. Das Redo-Protokoll befindet sich in der Transaktion Beginnen Sie mit der Aufzeichnung, wenn Sie beginnen

(Es wird nicht aufgezeichnet, wenn die Transaktion festgeschrieben wird, da die gesamte Transaktion möglicherweise viele Vorgänge ausführt. Wenn das Redo-Protokoll beim Festschreiben geschrieben wird und zu diesem Zeitpunkt eine Ausnahme auftritt, ist dies im Redo-Protokoll nicht der Fall wurde bereits geschrieben, was zu spät ist und die Haltbarkeit der Transaktion nicht gewährleistet werden kann. Wenn eine Ausnahme auftritt (z. B. ein Stromausfall während des Datenpersistenzprozesses), wird sie aufgezeichnet verwendet das Redo-Log, um den Zeitpunkt vor dem Stromausfall wiederherzustellen, um die Integrität der Daten sicherzustellen.

innodb_log_buffer_size ist standardmäßig auf 16 MB eingestellt, was der Größe des Redo-Log-Puffers entspricht, wenn die Transaktion beginnt Die Transaktion ist relativ groß. Um zu vermeiden, dass während der Transaktionsausführung zu viel Festplatten-IO ausgegeben wird, können Sie einen größeren Wert festlegen. Redo-Log-Cache spart Festplatten-IO. Es gibt eine Zeit zum Aktualisieren, wenn die Datenträger-E/A verbraucht ist, wenn die Zeit erreicht ist. Wenn der Puffer relativ groß ist, wird die Aktualisierungszeit langsamer erreicht und die Effizienz ist höher.

/var/lib/mysql

InnoDB ändert die Betriebsdaten, nicht direkt die Daten auf der Festplatte, sondern nur die Daten im Pufferpool

. InnoDB zeichnet die Datenänderungen im Pufferpool immer zuerst im Redo-Log auf, um die Daten nach einem Absturz wiederherzustellen. Zeichnen Sie zuerst das Redo-Protokoll auf und suchen Sie dann nach einer Gelegenheit, die fehlerhaften Daten im Pufferpool langsam auf der Festplatte zu aktualisieren. Zwei Dateien in dem durch innodb_log_group_home_dir angegebenen Verzeichnis: ib_logfile0, ib_logfile1, diese Datei wird als Redo-Protokoll bezeichnet

Pufferpool Cache-Pool:

Kann Index-Cache, Daten-Cache usw. speichern, kann das Lesen und Schreiben beschleunigen und Betreiben Sie die Datenseite direkt, auch wenn die Redo-Log-Änderung abgeschlossen ist, gibt es einen dedizierten Thread zum Schreiben der schmutzigen Seite im Pufferpool auf die Festplatte

Die Standardgröße des Pufferpools beträgt 134 MB (MySQL 5.7)

Die allgemeine Struktur ist wie in der Abbildung dargestellt:

Transaktionslesevorgänge und -änderungen priorisieren alle die Daten im Cache-Pool. In tatsächlichen Projekten wird mysqld auf einem separaten Computer ausgeführt, der eine große Menge Speicher speziell für den Pufferpool von InnoDB zuweisen kann, um CRUD 2 zu beschleunigen Das Bild besteht darin, den Inhalt des InnoDB-Protokollpuffers auf die Festplatte zu schreiben. Wenn das Schreiben erfolgreich ist, zeichnet das Redo-Protokoll auf der Festplatte den Status „Festschreiben“ auf. Wenn das Schreiben nicht erfolgreich ist oder abgeschlossen ist, wird der Status „Vorbereiten“ angezeigt aufgezeichnet.

Während des Schreibens des Protokolls auf die Festplatte können auch Anomalien, Stromausfälle und andere Probleme auftreten, die dazu führen, dass das Schreiben des Redo-Protokolls nicht abgeschlossen wird (dies ist gleichbedeutend damit, dass die Transaktion nicht erfolgreich festgeschrieben wurde). Zu diesem Zeitpunkt schlägt MySQL bei der nächsten Wiederherstellung fehl. Es besteht keine Notwendigkeit, die Integrität dieser Transaktion zu berücksichtigen, da der Status „Nicht festgeschrieben“ lautet. Nur wenn alles auf die Festplatte geschrieben wurde, wurde das Redo-Protokoll erfolgreich geschrieben. und der Status wird Commit. Nachdem sich der Status in „Commit“ geändert hat, müssen die ACID-Merkmale der Transaktion beibehalten werden.

Stimmt es, dass die schmutzigen Daten in der Pufferabfrage (die Daten wurden geändert) nur beim Festschreiben auf die Festplatte geschrieben werden?

Sie müssen nicht warten, bis der Commit beginnt. Die Datenmenge, die durch die Transaktion geändert werden kann, ist relativ groß und die Cache-Kapazität ist begrenzt. Für die in der Pufferabfrage zwischengespeicherten Daten gibt es einen dedizierten Thread, der die Festplatte zum richtigen Zeitpunkt aktualisiert Beim nächsten Start von MySQL wird es entsprechend der Wiederholung aktualisiert. Die im Protokoll aufgezeichneten Daten werden wiederhergestellt.

Undo-Log selbst wird auch im Redo-Log aufgezeichnet

Das Rückgängig-Protokoll unterstützt das Transaktions-Rollback und kann nicht sofort abgeschlossen werden. Um Ausnahmen während des Rollback-Vorgangs zu verhindern, muss das Rückgängig-Protokoll aufgezeichnet werden Wiederholen Sie die Anmeldung. Für die unterste Ebene gilt der Vorgang nach erfolgreichem Schreiben in das Redo-Protokoll als erfolgreich, unabhängig davon, ob die Transaktion erfolgreich festgeschrieben (festgeschrieben) oder erfolgreich zurückgesetzt (rollback) wurde.

Was ist ein echter Transaktions-Commit-Erfolg?

Anstatt alle Daten auf die Festplatte zu schreiben, wird das Redo-Log, das den gesamten Vorgang der Transaktion aufzeichnet, aus dem Protokollpuffer auf die Festplatte geschrieben und dann der Status Wenn der Wert der geänderten Daten auf „Commit“ gesetzt ist, gilt dies als erfolgreicher Transaktions-Commit. Obwohl sich die Daten zu diesem Zeitpunkt noch in der Pufferabfrage befinden, können die Daten wiederhergestellt werden, solange unser Redo-Protokoll vollständig gespeichert ist. Es gibt einen dedizierten Thread, der für das Schreiben der Daten in der Pufferabfrage auf die Festplatte #🎜🎜 verantwortlich ist #

#🎜🎜 #Wenn eine Transaktion ausgeführt wird, wird immer zuerst das Redo-Protokoll geschrieben, und dann wird der Pufferpool geschrieben. Das erfolgreiche Festschreiben der Transaktion soll sicherstellen, dass das Redo-Protokoll vollständig auf der Festplatte aufgezeichnet wird

Was die Änderungen an Tabellendaten betrifft, müssen wir uns keine Sorgen darüber machen, ob die schmutzigen Datenseiten des Pools auf die Festplatte geschrieben werden Auf der Festplatte können wir das Redo-Protokoll verwenden, um jederzeit den Datenstatus des erfolgreichen Commits der Transaktion wiederherzustellen (

Datenbank Das Wichtigste ist das Protokoll, nicht die Daten

)

Das obige ist der detaillierte Inhalt vonWas ist das Konzept von MySQL-Redo-Logs?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!