MySQL-Reihe: Redo-Log, Undo-Log und Binlog – ausführliche Erklärung

Durchführung von Transaktionen

Das Redo-Protokoll stellt die Persistenz der Transaktionen sicher und das Undo-Protokoll wird als Hilfe für Transaktions-Rollbacks und MVCC-Funktionen verwendet.

Architektur der InnoDB-Speicher-Engine

Redo-Protokoll

Write-Ahead-Log-Strategie

Beim Festschreiben einer Transaktion wird zuerst das Redo-Log geschrieben und dann die Seite geändert. Gehen durch einen Absturz Daten verloren, können diese über das Redo-Log wiederhergestellt werden.

• InnoDB legt zunächst die Redo-Log-Informationen in den Redo-Log-Cache
• Aktualisieren, um Protokolldateien in einer bestimmten Häufigkeit wiederherzustellen

Redo-Logdateien: Standardmäßig gibt es zwei Dateien mit den Namen ib_logfile1 und ib_logfile2 im Datenverzeichnis der InnoDB-Speicher-Engine. Jede InnoDB-Speicher-Engine verfügt über mindestens eine Redo-Log-Dateigruppe und jede Dateigruppe verfügt über mindestens zwei Redo-Log-Dateien.

Die folgende Abbildung 1 zeigt, dass die Redo-Log-Gruppe im zirkulären Schreibmodus ausgeführt wird. Die InnoDB-Speicher-Engine schreibt zuerst ib_logfile1 und wechselt am Ende der Datei zur Redo-Log-Datei ib_logfile2.

Wie in Abbildung 2 dargestellt, hilft das Hinzufügen eines OS-Puffers, den fsync-Prozess zu verstehen.

Die Protokollgruppe wird als Redo-Protokollgruppe bezeichnet, was ein logisches Konzept ist. Die InnoDB-Speicher-Engine hat eigentlich nur eine Protokollgruppe.

Die erste Redo-Logdatei in der Loggruppe speichert in ihren ersten 2 KB vier 512-Byte-Blöcke:

Redo-Log-Puffer auf die Festplatte geleert

Die folgenden drei Situationen aktualisieren:

• Der Master-Thread leert den Redo-Log-Puffer jede Sekunde in die Redo-Log-Datei.
• Wenn jede Transaktion festgeschrieben wird, wird der Redo-Log-Puffer in die Redo-Log-Datei geleert.
• Wenn der verbleibende Speicherplatz im Redo-Log-Pufferpool weniger als 1/2 beträgt, wird das Redo-Log in die Redo-Log-Datei geschrieben.

Als Ergänzung zur zweiten der drei oben genannten Situationen wird das Auslösen des Festplattenschreibvorgangs durch den Parameter innodb_flush_log_at_trx_commit gesteuert, der angibt, wie mit dem Redo-Protokoll beim Ausführen des Commit-Vorgangs umgegangen werden soll.

Die gültigen Werte des Parameters innodb_flush_log_at_trx_commit sind 0, 1 und 2.

• 0 bedeutet, dass beim Festschreiben einer Transaktion das Redo-Protokoll der Transaktion nicht in die Protokolldatei auf der Festplatte geschrieben wird, sondern darauf gewartet wird, dass der Hauptthread es jede Sekunde aktualisiert.
• 1 bedeutet, dass der Redo-Log-Puffer beim Ausführen des Commits synchron auf die Festplatte geschrieben wird, d. h. begleitet von einem Aufruf von fsync
• 2 bedeutet, dass das Redo-Protokoll asynchron auf die Festplatte geschrieben wird, d. h., es wird in den Cache des Dateisystems geschrieben. Es gibt keine Garantie, dass die Redo-Log-Datei beim Commit geschrieben wird.

0. Wenn die Datenbank abstürzt, werden einige Protokolle nicht auf die Festplatte geschrieben, sodass die Transaktionen des letzten Zeitraums verloren gehen.
2. Wenn das Betriebssystem abstürzt, geht der Teil der Transaktion, der nicht aus dem Dateisystemcache in die Redo-Logdatei geleert wurde, nach dem Neustart der Datenbank verloren.

Das folgende Diagramm hilft zu verstehen

Redo-Log-Blöcke

In der InnoDB-Speicher-Engine werden Redo-Protokolle in 512 Bytes gespeichert. Dies bedeutet, dass der Redo-Log-Cache und die Redo-Log-Dateien in Blöcken gespeichert werden, wobei jeder Block 512 Byte groß ist.

Der Redo-Log-Header ist 12 Bytes groß und das Redo-Log-Ende 8 Bytes, sodass jeder Redo-Log-Block tatsächlich 492 Bytes speichern kann.

Redo-Log-Format

Das Redo-Protokoll wird seitenweise aufgezeichnet. Standardmäßig beträgt die Seitengröße von InnoDB 16 KB (gesteuert durch die Variable innodb_page_size). Eine Seite kann eine große Anzahl von Protokollblöcken (jeweils 512 Byte) speichern, und die Protokollblöcke zeichnen die Änderungen auf den Datenseiten auf.

Das Format des Protokollkörpers ist in vier Teile unterteilt:

• redo_log_type: belegt 1 Byte und gibt den Protokolltyp des Redo-Protokolls an.
• space: Gibt die ID des Tablespace an. Nach der Komprimierung kann der belegte Speicherplatz weniger als 4 Byte betragen.
• page_no: Gibt den Seitenoffset an, der ebenfalls komprimiert wird.
• redo_log_body stellt den Datenteil jedes Redo-Protokolls dar und die entsprechende Funktion wird während der Wiederherstellung zum Parsen aufgerufen. Beispielsweise sind die von einer Insert-Anweisung und einer Delete-Anweisung in das Redo-Protokoll geschriebenen Inhalte unterschiedlich.

Die folgenden Abbildungen zeigen die allgemeinen Aufzeichnungsmethoden Einfügen und Löschen.

Redo-Log-Wiederherstellung

Die folgende LSN (Log Sequence Number) stellt den Prüfpunkt dar. Wenn die Datenbank bei LSN 10000 abstürzt, stellt der Wiederherstellungsvorgang nur Protokolle im Bereich LSN10000-LSN13000 wieder her.

Undo-Protokoll

Die Rolle des Undo-Logs

Undo ist ein logisches Protokoll, das die Datenbank einfach logisch in ihren ursprünglichen Zustand zurückversetzt; alle Änderungen werden logisch rückgängig gemacht, aber die Datenstruktur und die Seite selbst können nach dem Rollback anders sein.

Das Undo-Protokoll hat zwei Funktionen: Es ermöglicht Rollback und mehrzeilige Versionskontrolle (MVCC).

Wenn die InnoDB-Speicher-Engine ein Rollback durchführt, wird für jedes INSERT ein DELETE abgeschlossen, für jedes DELETE ein INSERT ausgeführt und für jedes UPDATE ein umgekehrtes UPDATE ausgeführt, um die vorherige Zeile wiederherzustellen.

MVCC: Wenn ein Benutzer eine Datensatzzeile liest und der Datensatz bereits von anderen Transaktionen belegt ist, kann die aktuelle Transaktion durch Rückgängigmachen die Versionsinformationen der vorherigen Zeile lesen und so ein Lesen ohne Sperren erreichen.

Undo-Log-Speichermethode

Die InnoDB-Speicher-Engine verwaltet das Rückgängigmachen in Segmenten. Das Rollback-Segment wird als Rollback-Segment bezeichnet und jedes Rollback-Segment verfügt über 1024 Undo-Log-Segmente.

In der alten Version wurde nur ein Rollback-Segment unterstützt, daher konnten nur 1024 Undo-Log-Segmente aufgezeichnet werden. Später kann MySQL 5.5 128 Rollback-Segmente unterstützen, d. h. 128*1024 Rückgängig-Vorgänge. Sie können die Anzahl der Rollback-Segmente auch über die Variable innodb_undo_logs anpassen (vor Version 5.6 war diese Variable innodb_rollback_segments). Der Standardwert ist 128.

Undo-Protokolle werden standardmäßig im gemeinsam genutzten Tablespace gespeichert.

Verarbeitung des Undo-Protokolls für Transaktions-Commits

Wenn eine Transaktion festgeschrieben wird, führt die InnoDB-Speicher-Engine die folgenden zwei Dinge aus:

• Das Undo-Log wird in eine Liste zur späteren Bereinigung eingetragen. Ob das Undo-Log und die Seite, auf der es sich befindet, endgültig gelöscht werden können, wird vom Bereinigungsthread bestimmt.
• Stellen Sie fest, ob die Seite, auf der sich das Undo-Log befindet, wiederverwendet werden kann. Wenn ja, ordnen Sie es der nächsten Transaktion zu.

Wenn eine Transaktion festgeschrieben wird, wird das Rückgängig-Protokoll zuerst in die verknüpfte Liste eingefügt und dann ermittelt, ob der verwendete Speicherplatz der Rückgängig-Seite weniger als 3/4 beträgt. Wenn dies der Fall ist, bedeutet dies, dass die Rückgängig-Seite wiederverwendet werden kann, und dann wird das neue Rückgängig-Protokoll nach dem aktuellen Rückgängig-Protokoll aufgezeichnet.

Das Undo-Protokoll ist unterteilt in:

• Undo-Protokoll einfügen
• Undo-Protokoll aktualisieren

Aufgrund der Transaktionsisolation ist das Einfüge-Undo-Protokoll für andere Transaktionen nicht sichtbar, sodass das Undo-Protokoll direkt nach dem Festschreiben der Transaktion gelöscht werden kann, ohne dass ein Bereinigungsvorgang erforderlich ist.

Das Update-Undo-Protokoll zeichnet die Undo-Protokolle auf, die durch Lösch- und Aktualisierungsvorgänge generiert werden. Das Undo-Protokoll muss möglicherweise einen MVCC-Mechanismus bereitstellen, sodass es beim Senden nicht gelöscht werden kann.

Für die Aktualisierung gibt es zwei Fälle:

• Handelt es sich bei der Datumsspalte nicht um eine Primärschlüsselspalte, wird im Undo-Log direkt die Aktualisierung in umgekehrter Reihenfolge aufgezeichnet. Das heißt, das Update wird direkt durchgeführt.
• Der Vorgang zum Aktualisieren des Primärschlüssels kann in zwei Schritte unterteilt werden:
• Markieren Sie zunächst den ursprünglichen Primärschlüsseldatensatz als gelöscht, sodass ein Undo-Protokoll vom Typ TRX_UNDO_DEL_MARK_REC generiert werden muss.
• Anschließend wird ein neuer Datensatz eingefügt, wodurch ein Undo-Protokoll vom Typ TRX_UNDO_INSERT_MARK_REC erzeugt wird.

Wenn InnoDB bereinigt, sucht es zuerst in der Verlaufsliste nach dem Undo-Protokoll und dann auf der Undo-Seite nach dem Undo-Protokoll. Dadurch können viele zufällige Lesevorgänge vermieden und die Bereinigungseffizienz verbessert werden.

MVCC (Mehrversionen-Parallelitätskontrolle)

MVCC fügt tatsächlich nach jeder Datensatzzeile zwei versteckte Spalten hinzu, um die Erstellungsversionsnummer und die Löschversionsnummer aufzuzeichnen. Wenn jede Transaktion gestartet wird, hat sie eine eindeutige, inkrementelle Versionsnummer.

MVCC funktioniert nur auf den Isolationsebenen REPEATABLE READ und READ COMMITTED. Beim nicht festgeschriebenen Lesen gibt es kein Versionsproblem, und die Serialisierung sperrt alle gelesenen Zeilen.

Beispiel:

Einfügevorgang: Die Erstellungsversionsnummer des Datensatzes ist die Transaktionsversionsnummer

Wenn Sie einen Datensatz einfügen, wird angenommen, dass die Transaktions-ID 1 ist und die Erstellungsversionsnummer ebenfalls 1 ist