Detaillierte Erläuterung des MySQL-Redo-Logs (Redo-Log) und des Rollback-Logs (Undo-Log)

Vorwort:

Im vorherigen Artikel wurden mehrere allgemeine Protokolle im MySQL-System beschrieben. Tatsächlich gibt es transaktionsbezogene Protokolle, Redo-Protokolle und Undo-Protokolle, die nicht eingeführt wurden. Im Vergleich zu anderen Protokollen sind das Redo-Protokoll und das Undo-Protokoll mysteriöser und schwieriger zu beobachten. In diesem Artikel werden hauptsächlich die Funktionen sowie die Betriebs- und Wartungsmethoden dieser beiden Arten von Transaktionsprotokollen vorgestellt.

1. Protokoll wiederholen

Wir alle wissen, dass Persistenz eines der vier Hauptmerkmale von Transaktionen ist. Insbesondere werden die an der Datenbank vorgenommenen Änderungen dauerhaft gespeichert, solange die Transaktion erfolgreich übermittelt wird, und es ist aus keinem Grund möglich, zum ursprünglichen Zustand zurückzukehren. Wie stellt MySQL also Konsistenz 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 nicht physisch zusammenhängend, sodass die Leistung bei der Verwendung von zufälligen IO-Schreibvorgängen zu schlecht ist.
  

Aus diesem Grund hat MySQL ein Redo-Protokoll entwickelt, das speziell nur die von Transaktionen an der Datenseite vorgenommenen Änderungen aufzeichnet. Dadurch können Leistungsprobleme perfekt gelöst werden (relativ gesehen ist die Datei kleiner und es handelt sich um sequentielle E/A).

Das Redo-Log besteht aus zwei Teilen: Der eine ist der Log-Puffer im Speicher (Redo-Log-Puffer) und der andere ist die Log-Datei auf der Festplatte (Redo-Log-Datei). Jedes Mal, wenn MySQL eine DML-Anweisung ausführt, schreibt es zuerst den Datensatz in den Redo-Log-Puffer und dann zu einem bestimmten Zeitpunkt mehrere Operationsdatensätze in die Redo-Log-Datei.

Standardmäßig wird das Redo-Protokoll auf der Festplatte durch zwei physische Dateien mit den Namen ib_logfile0 und ib_logfile1 dargestellt. Die mit dem Redo-Log in Zusammenhang stehenden Parameter werden im Folgenden kurz vorgestellt:

• innodb_log_files_in_group: Die Anzahl der Redo-Logdateien, benannt als ib_logfile0, iblogfile1...iblogfilen. Der Standardwert ist 2 und der Höchstwert ist 100.
• innodb_log_file_size: Legen Sie die Größe einer einzelnen Redo-Logdatei fest. Der Standardwert beträgt 48 MB und der Maximalwert 512 GB. Beachten Sie, dass sich der Maximalwert auf die Summe der gesamten Redo-Logdateireihe bezieht, d. h. (innodb_log_files_in_group * innodb_log_file_size) kann nicht größer als der Maximalwert von 512 GB sein.
• innodb_log_group_home_dir: Gibt den Pfad an, in dem sich die Redo-Logdateigruppe befindet. Der Standardwert ist ./, was bedeutet, dass sie sich im Datenbankdatenverzeichnis befindet.
• innodb_log_buffer_size: Redo-Log-Puffergröße, Standard 16 M. Verzögern Sie das Schreiben des Transaktionsprotokolls auf die Festplatte, legen Sie das Redo-Protokoll in den Puffer und leeren Sie das Protokoll dann entsprechend der Einstellung des Parameters innodb_flush_log_at_trx_commit aus dem Puffer auf die Festplatte.
• innodb_flush_log_at_trx_commit: Steuert die Strategie zum Leeren des Redo-Protokolls auf die Festplatte. Der Standardwert ist 1. Wenn der Wert 1 ist, schreibt jedes Commit das Redo-Log aus dem Redo-Log-Puffer in das System und synchronisiert es per Fsync in die Datenträgerdatei. Wenn der Wert 2 ist, schreibt MySQL bei jedem Festschreiben einer Transaktion das Protokoll aus dem Redo-Log-Puffer in das System, jedoch nur in den Dateisystempuffer, der vom System selbst mit der Festplattendatei synchronisiert wird. Wenn die Datenbankinstanz abstürzt, geht das Redo-Protokoll nicht verloren. Wenn jedoch der Server abstürzt, hat der Dateisystempuffer keine Zeit, mit der Festplattendatei zu synchronisieren, sodass dieser Teil der Daten verloren geht. Ein Wert von 0 gibt an, dass das Redo-Protokoll nicht geschrieben wird, wenn die Transaktion festgeschrieben wird. Dieser Vorgang wird nur im Master-Thread abgeschlossen, und der Fsync-Vorgang des Redo-Protokolls wird im Master-Thread einmal pro Sekunde ausgeführt. Wenn die Instanz abstürzt, gehen daher höchstens Transaktionen innerhalb von 1 Sekunde verloren.
  

Das Ändern des Redo-Logs und seiner Puffergröße erfordert einen Neustart der Datenbankinstanz. Es wird empfohlen, während der Initialisierung eine Bewertung vorzunehmen. Sie können die Anzahl und Größe der Redo-Log-Gruppen entsprechend erhöhen, insbesondere wenn Ihre Datenbankinstanz häufig aktualisiert wird. Es wird jedoch nicht empfohlen, die Redo-Log-Größe zu groß einzustellen.

2. Protokoll rückgängig machen

Das Undo-Log wird hauptsächlich verwendet, um die Atomizität von Daten sicherzustellen. Es speichert eine Version der Daten, bevor die Transaktion erfolgt, und kann zum Rollback verwendet werden. Beispielsweise gibt es für eine INSERT-Anweisung ein entsprechendes Undo-Protokoll für DELETE und für jede UPDATE-Anweisung ein entsprechendes Undo-Protokoll für das entgegengesetzte UPDATE, sodass die Daten bei Auftreten eines Fehlers auf den Zustand vor der Transaktion zurückgesetzt werden können. Gleichzeitig ist das Undo-Log auch der Schlüssel zur Implementierung von MVCC (Multi-Version Concurrency Control).

In MySQL 5.7 werden Undo-Protokolle standardmäßig im gemeinsam genutzten Tablespace ibdata gespeichert. Sie können es auch in eine separate Datei ändern, indem Sie während der Initialisierung Parameter konfigurieren. Hier sind einige mit dem Undo-Log verbundene Parameter:

• innodb_max_undo_log_size: steuert die maximale Größe der Undo-Tablespace-Datei. Wenn innodb_undo_log_truncate aktiviert ist, wird Truncate nur versucht, wenn der Undo-Tablespace den innodb_max_undo_log_size-Schwellenwert überschreitet. Der Standardwert ist 1 G und der Standardwert nach der Kürzung ist 10 M.
• innodb_undo_tablespaces: Legen Sie die Anzahl unabhängiger Undo-Tablespaces im Bereich von 0 bis 128 fest. Der Standardwert in Version 5.7 ist 0, was bedeutet, dass der unabhängige Undo-Tablespace nicht aktiviert ist. Dieser Parameter kann nur beim ersten Initialisieren der MySQL-Instanz angegeben werden.
• innodb_undo_directory: Legen Sie das Speicherverzeichnis des Undo-Tablespace fest, das Standarddatenverzeichnis.
• innodb_undo_log_truncate: Legt fest, ob der Undo-Tablespace automatisch gekürzt und wiederverwendet wird. Voraussetzung für die Wirkung dieses Parameters ist, dass unabhängige Tablespaces festgelegt wurden und die Anzahl der unabhängigen Tablespaces größer oder gleich 2 ist.
  

Mit dem Undo-Protokoll verbundene Parameter werden selten geändert. MySQL 8.0 aktiviert standardmäßig unabhängige Tablespaces, was die Größeneinstellung des Undo-Log-Tablespaces flexibler machen kann.

Zusammenfassen:

In diesem Artikel werden hauptsächlich die Funktionen des Redo-Logs und des Undo-Logs sowie die zugehörigen Parametereinstellungen vorgestellt. Der Artikel wurde in Eile geschrieben. Wenn Fehler auftreten, hinterlassen Sie bitte eine Nachricht, um darauf hinzuweisen. Was die tieferen Inhalte dieser beiden Protokolltypen angeht, ist der Autor vielleicht noch nicht kompetent genug, um ausführlicher zu schreiben. Nun, es wurden zwei Artikel über MySQL-bezogene Protokolle geschrieben. Ich hoffe, Sie können etwas lernen.