Detaillierte Erläuterung des Redo-Logs und Undo-Logs in MySQL

Die wichtigsten Protokolle im MySQL-Protokollsystem sind das Redo-Protokoll und das Archivprotokoll. Letzteres ist das Protokoll der MySQL-Serverschicht und ersteres ist das Protokoll der InnoDB-Speicher-Engine-Schicht.

1 Redo-Protokoll

1.1 Was ist ein Redo-Log?

Das Redo-Protokoll wird verwendet, um die Dauerhaftigkeit von Transaktionen sicherzustellen; das ist das D in ACID.

Persistenz: Sobald eine Transaktion festgeschrieben ist, sind die an den Daten in der Datenbank vorgenommenen Änderungen dauerhaft und sollten von einem nachfolgenden Datenbankfehler nicht betroffen sein.

Es gibt zwei Arten von Redo-Logs: physische Redo-Logs und logische Redo-Logs. In InnoDB ist das Redo-Log in den meisten Fällen ein physisches Protokoll, das die physischen Änderungen von Datenseiten (tatsächliche Datenwerte) aufzeichnet.

1.2 Funktionen des Redo-Logs

Die Hauptfunktion des Redo-Logs besteht darin, Daten bei einem Datenbankabsturz wiederherzustellen.

1.3 Zusammensetzung des Redo-Logs

Das Redo-Log kann in die folgenden zwei Teile unterteilt werden

Der im Speicher abgelegte Redo-Log-Puffer und die auf der Festplatte abgelegten Redo-Log-Dateien

1.4 Wann sollten Redo-Protokolle aufgezeichnet werden?

Nachdem die Datenänderung abgeschlossen ist, wird die fehlerhafte Seite in den Redo-Log-Puffer geschrieben, bevor sie auf die Festplatte geleert wird. Das heißt: Erst ändern, dann schreiben.

Schmutzige Seiten: Daten im Speicher, die nicht mit den Daten auf der Festplatte übereinstimmen (nicht schlecht!)

In den folgenden Fällen werden Redo-Logs aus dem Redo-Log-Puffer in Redo-Log-Dateien auf der Festplatte geschrieben.

• Wenn die Protokolle des Redo-Log-Puffers die Hälfte der Gesamtkapazität des Redo-Log-Puffers belegen, werden die Redo-Protokolle auf die Festplatte geschrieben.
• Wenn eine Transaktion festgeschrieben wird, wird ihr Redo-Protokoll auf die Festplatte geschrieben. Dadurch wird sichergestellt, dass keine Daten verloren gehen (was am häufigsten der Fall ist). Beachten Sie, dass zu diesem Zeitpunkt möglicherweise noch nicht alle schmutzigen Seiten im Speicher auf die Festplatte geschrieben wurden.
• Der Hintergrund-Thread wird regelmäßig aktualisiert, und es gibt einen Hintergrund-Thread, der das Redo-Protokoll jede Sekunde auf die Festplatte schreibt.
• Wenn MySQL heruntergefahren wird, werden Redo-Protokolle auf die Festplatte geschrieben.

Im ersten und vierten Fall werden auf jeden Fall Redo-Logs geschrieben. Die Ausführung im zweiten und dritten Fall hängt vom Einstellungswert des Parameters innodb_flush_log_at_trx_commit ab, der weiter unten ausführlich beschrieben wird.

Für die Erstellung eines Indexes ist auch die Aufzeichnung des Redo-Logs erforderlich.

1.5 Ein Beispiel für die Wiederholung des gesamten Prozesses

Nehmen Sie Aktualisierungstransaktionen als Beispiel.

• Lesen Sie die Originaldaten in den Speicher und ändern Sie die Kopie der Daten im Speicher.
• Erzeugen Sie ein Redo-Log und schreiben Sie es in den Redo-Log-Puffer. Das Redo-Log speichert den neuen Wert nach der Änderung.
• Wenn eine Transaktion festgeschrieben wird, wird der Inhalt des Redo-Log-Puffers in die Redo-Log-Datei geschrieben.
• Die schmutzigen Seiten im Speicher werden dann normal auf die Festplatte zurückgeschrieben.

1.6 Garantie der Persistenz

1.6.1 Mechanismus zum Erzwingen des Logs beim Commit

Der Force Log at Commit-Mechanismus implementiert die Transaktionspersistenz. Beim Betrieb im Speicher werden Protokolle in den Redo-Log-Puffer geschrieben. Bevor jedoch eine Transaktion festgeschrieben werden kann, müssen zunächst alle Protokolle in die Redo-Log-Dateien auf der Festplatte geschrieben werden.

Um sicherzustellen, dass jedes Protokoll in die Redo-Logdatei geschrieben wird, muss ein fsync-Systemaufruf verwendet werden, um sicherzustellen, dass das Protokoll im OS-Puffer vollständig in die Protokolldatei auf der Festplatte geschrieben wird.

fsync-Systemaufruf: Sie müssen ihm ein fd als Eingabeparameter übergeben, dann wird der Systemaufruf mit der Datei arbeiten, auf die dieses fd zeigt. fsync stellt sicher, dass es nicht zurückkehrt, bis der Schreibvorgang auf die Festplatte abgeschlossen ist. Wenn Ihr Programm diese Funktion also verwendet und sie erfolgreich zurückkehrt, bedeutet das, dass die Daten sicher auf die Festplatte geschrieben worden sein müssen. Daher eignet sich fsync für Programme wie Datenbanken.

1.6.2 innodb_flush_log_at_trx_commit-Parameter

InnoDB bietet einen Parameter innodb_flush_log_at_trx_commit , um die Strategie zum Leeren von Protokollen auf die Festplatte zu steuern.

• Wenn der Wert innodb_flush_log_at_trx_commit 1 ist (Standard). Bei jedem Festschreiben einer Transaktion muss das Protokoll im Protokollpuffer in den Betriebssystempuffer geschrieben und fsync() aufgerufen werden, um es auf die Festplatte zu schreiben.

Bei dieser Methode gehen auch bei einem Systemabsturz keine Daten verloren, da jedoch jede Übermittlung auf die Festplatte geschrieben wird, ist die E/A-Leistung schlecht.

• Wenn innodb_flush_log_at_trx_commit Wert 0 ist. Wenn eine Transaktion festgeschrieben wird, wird der Protokollpuffer nicht in den Betriebssystempuffer geschrieben. Stattdessen wird er jede Sekunde in den Betriebssystempuffer geschrieben und fsync() wird aufgerufen, um ihn in die Protokolldatei auf der Festplatte zu schreiben.

Dies entspricht tatsächlich der Pflege eines benutzerdefinierten Puffers im Speicher, wodurch die Datenübertragung zwischen dem Betriebssystempuffer reduziert wird und eine bessere Leistung erzielt wird.

Bei einem Systemabsturz gehen 1 Sekunde Daten verloren, wenn jede Sekunde auf die Festplatte geschrieben wird.

• Wenn innodb_flush_log_at_trx_commit -Wert 2 ist. Jedes Commit wird nur in den OS-Puffer geschrieben und dann wird jede Sekunde fsync() aufgerufen, um die Protokolle im OS-Puffer in die Protokolldatei auf der Festplatte zu schreiben.

Obwohl wir fsync() jede Sekunde aufrufen, um die Protokolle im Betriebssystempuffer in die Protokolldatei auf der Festplatte zu schreiben, werden die Daten nach und nach selbstständig auf die Festplatte übertragen, auch wenn fsync zu anderen Zeiten nicht aufgerufen wird. Bei einem Systemabsturz gehen also im Vergleich zum zweiten Fall weniger Daten verloren.

Da jedoch gleichzeitig jede Übermittlung in den Betriebssystempuffer geschrieben wird, ist die Leistung schlechter als im zweiten Fall, aber immer noch besser als im ersten Fall.

In beiden Fällen

1.6.3 Ein kleiner Leistungstest

Der Leistungsunterschied zwischen den Optionen ist enorm. Machen wir einen einfachen Test.

#Erstellen Sie eine Testtabelle. Löschen Sie die Tabelle, falls vorhanden. Test_flush_log;
Tabelle erstellen test_flush_log(id int,name char(50))engine=innodb;

#Erstellen Sie eine gespeicherte Prozedur, um eine angegebene Anzahl von Zeilen in die Testtabelle einzufügen. Drop-Prozedur, falls vorhanden.
Trennzeichen $$
Prozedur proc(i int) erstellen
beginnen
    deklariere s int default 1;
    Deklarieren Sie c char (50) als Standardwiederholung ('a', 50);
    während s<=i
        Transaktion starten;
        in test_flush_log-Werte (null, c) einfügen;
        begehen;
        setze s=s+1;
    Ende während;
Ende$$
Trennzeichen ;

Unten werden einhunderttausend Datensätze eingefügt.

Ⅰ Wenn der Wert innodb_flush_log_at_trx_commit 1 ist

Test> Aufrufproc(100000)
[2021-07-25 13:22:02] abgeschlossen in 27 s 350 ms

Es dauert bis zu 27,35 Sekunden.

Ⅱ Wenn der Wert innodb_flush_log_at_trx_commit 2 ist

Test> setze @@global.innodb_flush_log_at_trx_commit=2;    
Test> Test_Flush_Log abschneiden;

Test> Aufrufproc(100000)
[2021-07-25 13:27:33] abgeschlossen in 5 s 774 ms

Es dauert nur 5,774 Sekunden, was die Leistung erheblich verbessert.

III Wenn der Wert innodb_flush_log_at_trx_commit 0 ist

Test> setze @@global.innodb_flush_log_at_trx_commit=0;
Test> Test_Flush_Log abschneiden;

Test> Aufrufproc(100000)
[2021-07-25 13:30:34] abgeschlossen in 3 s 537 ms

Es dauert nur 3,537 Sekunden und bietet eine höhere Leistung.

Offensichtlich ist die Leistung sehr schlecht, wenn innodb_flush_log_at_trx_commit 1 ist. Nach der Änderung auf 0 und 2 verbessert sich die Leistung erheblich. 0 ist schneller, aber nicht viel besser als 2.

Obwohl eine Änderung auf 0 und 2 die Leistung erheblich verbessern kann, wird die Sicherheit dadurch ernsthaft beeinträchtigt. Wir können die gespeicherte Prozedur ändern, die Erstellung und Übermittlung von Transaktionen außerhalb der Schleife platzieren, sie einheitlich übermitteln und die IO-Frequenz reduzieren.

Prozedur löschen, falls Prozedur existiert;
Trennzeichen $$
Prozedur proc(i int) erstellen
beginnen
    deklariere s int default 1;
    Deklarieren Sie c char (50) als Standardwiederholung ('a', 50);
    Transaktion starten;
    während s<=i DO
        in test_flush_log-Werte (null, c) einfügen;
        setze s=s+1;
    Ende während;
    begehen;
Ende$$
Trennzeichen ;

1.6.4 Mini-Transaktion

Minitransaktionen sind ein Mechanismus, der von InnoDB zur Verarbeitung kleiner Transaktionen verwendet wird. Sie können die Datenkonsistenz auf der Datenseite sicherstellen, wenn gleichzeitige Transaktionsvorgänge und Datenbankausnahmen auftreten.

Mini-Transaktionen müssen den folgenden drei Protokollen folgen:

• FIX-Regeln. Beim Schreiben muss eine exklusive Sperre und beim Lesen eine gemeinsame Sperre verwendet werden. Auf jeden Fall muss es verschlossen sein.
• Write-Ahead-Protokoll. Write-Ahead-Protokoll (WAL) Bevor Sie Daten dauerhaft speichern, müssen Sie zunächst das Protokoll im Speicher dauerhaft speichern. Jede Seite hat eine LSN (Log Sequence Number). Bevor Daten auf die Festplatte geschrieben werden, müssen Protokolle im Speicher mit Sequenznummern kleiner als LSN zuerst auf die Festplatte geschrieben werden. WAL bietet drei Persistenzmodi

Am strengsten ist die Vollsynchronisierung. Fsync stellt sicher, dass der Datensatz vor der Rückgabe auf die Festplatte geschrieben wird, wodurch die Datensicherheit maximiert wird.

Die zweite Ebene ist schreibgeschützt und stellt sicher, dass die Datensätze in das Betriebssystem geschrieben werden. Dadurch können Daten Abstürze auf Prozessebene überstehen.

Am wenigsten streng ist die No-Sync-Methode. Dabei werden die Datensätze in einem Speicherpuffer aufbewahrt und kein sofortiges Schreiben in das Dateisystem garantiert.

Erzwingen Sie eine erneute Übermittlung des Protokolls. Dabei handelt es sich um „Force-log-at-commit“, das erfordert, dass alle Minitransaktionsprotokolle auf die Festplatte geschrieben werden, wenn eine Transaktion festgeschrieben wird.

1.7 Der Prozess des Schreibens des Redo-Protokolls

Die obige Abbildung zeigt, wie das Redo-Log in den Log-Puffer geschrieben wird. Jede Minitransaktion entspricht einer DML-Operation, beispielsweise einer Aktualisierungsanweisung.

• Jede Datenänderung wird in den privaten Minitransaktionspuffer geschrieben.
• Wenn die Aktualisierungsanweisung abgeschlossen ist, wird das Redo-Protokoll aus dem privaten Minitransaktionspuffer in den öffentlichen Protokollpuffer im Speicher geschrieben.
• Wenn eine externe Transaktion festgeschrieben wird, wird der Redo-Log-Puffer in die Redo-Log-Dateien geleert.

1.8 Protokollblock

Das Redo-Protokoll wird in Blöcken gespeichert und jeder Block ist 512 Byte groß. Ob im Speicher-Redo-Log-Puffer, im Betriebssystempuffer oder in der Redo-Log-Datei, die Speicherung erfolgt in entsprechenden 512-Byte-Blöcken.

Jeder Protokollblockkopf besteht aus den folgenden vier Teilen

• log_block_hdr_no: (4 Bytes) Die Standort-ID des Protokollblocks im Redo-Log-Puffer.
• log_block_hdr_data_len: (2 Bytes) Die Größe des in diesem Protokollblock aufgezeichneten Protokolls. Wenn der Protokollblock voll ist, beträgt er 0x200, also 512 Bytes.
• log_block_first_rec_group: (2 Bytes) Die Start-Offsetposition des ersten Protokolls im Protokollblock.
• lock_block_checkpoint_no: (4 Bytes) Der Speicherort, an dem die Checkpoint-Informationen geschrieben werden.

1.9 Protokollgruppe

Die Protokollgruppe stellt die Gruppierung von Redo-Protokollen dar, die aus mehreren Redo-Protokolldateien derselben Größe besteht. Wird durch einen Parameter innodb_log_files_group bestimmt, der Standardwert ist 2.
[Bildübertragung über externen Link fehlgeschlagen, die Quellseite verfügt möglicherweise über einen Diebstahlschutzmechanismus. Es wird empfohlen, das Bild zu speichern und direkt hochzuladen (img-h01w68EG-1627284031849)(G:\markdown\MySQL\image-20210726131134489.png)].png)]

Diese Gruppe ist ein logisches Konzept, aber das Gruppenverzeichnis kann durch die Variable innodb_log_group_home_dir definiert werden. Die Redo-Logdateien werden in diesem Verzeichnis abgelegt, das sich standardmäßig unter datadir befindet.

2 Undo-Protokoll

2.1 Informationen zum Undo-Protokoll

Der Zweck des Undo-Protokolls besteht darin, die Atomizität von Datenbanktransaktionen sicherzustellen.

Atomarität bedeutet, dass eine Transaktion eine unteilbare Arbeitseinheit ist und entweder alle Vorgänge einer Transaktion ausgeführt werden oder keiner von ihnen.

• Das EDO-Protokoll zeichnet das Verhalten von Transaktionen auf, wodurch die Konsistenz sichergestellt und die Daten „wiederholt“ werden können. Manchmal müssen Transaktionen jedoch zurückgesetzt werden. In diesem Fall ist ein Undo-Protokoll erforderlich. Wenn wir Änderungen an Datensätzen vornehmen, müssen wir ein Undo-Protokoll generieren, das die alte Version der Daten aufzeichnet. Wenn die alte Transaktion die Daten lesen muss, kann sie der Undo-Kette folgen, um den Datensatz zu finden, der ihre Sichtbarkeit erfüllt.
• Undo-Protokolle liegen üblicherweise in Form von logischen Protokollen vor. Wir können davon ausgehen, dass beim Löschen eines Datensatzes das Rückgängig-Protokoll einen entsprechenden Einfügedatensatz generiert und umgekehrt. Wenn ein Datensatz aktualisiert wird, wird ein Zähleraktualisierungsdatensatz generiert.
• Undo-Protokolle werden in Segmenten aufgezeichnet. Jeder Undo-Vorgang belegt bei der Aufzeichnung ein Undo-Protokollsegment.
• Das Undo-Protokoll generiert auch ein Redo-Protokoll, da das Undo-Protokoll auch einen dauerhaften Schutz gewährleisten muss.

Undo-Protokolle liegen üblicherweise in Form von logischen Protokollen vor. Wir können davon ausgehen, dass beim Löschen eines Datensatzes das Rückgängig-Protokoll einen entsprechenden Einfügedatensatz generiert und umgekehrt. Wenn ein Datensatz aktualisiert wird, wird ein Zähleraktualisierungsdatensatz generiert.

Undo-Protokolle werden in Segmenten aufgezeichnet. Jeder Undo-Vorgang belegt bei der Aufzeichnung ein Undo-Protokollsegment.

Das Undo-Protokoll generiert auch ein Redo-Protokoll, da das Undo-Protokoll auch einen dauerhaften Schutz gewährleisten muss.

2.2 Log-Segment rückgängig machen

Um sicherzustellen, dass es beim Schreiben der jeweiligen Undo-Protokolle während gleichzeitiger Vorgänge zu keinen Konflikten zwischen Transaktionen kommt, verwaltet nnodb die Undo-Protokolle in Segmenten. Das Rollback-Segment wird als Rollback-Segment bezeichnet und jedes Rollback-Segment verfügt über 1024 Undo-Log-Segmente. MySQL-Versionen nach 5.5 unterstützen 128 Rollback-Segmente, die 128*1024 Operationen speichern können. Sie können ein Rollback-Segment auch mit dem Parameter innodb_undo_logs definieren.

2.3 Säuberung

MySQL ist für die Verarbeitung von gruppierten Indexspalten folgendermaßen konzipiert. Für eine Löschanweisung

lösche aus t, wobei a = 1

Wenn a einen gruppierten Index (Primärschlüssel) hat, wird keine tatsächliche Löschung durchgeführt. Stattdessen wird das Löschflag für den Datensatz auf 1 gesetzt, bei dem die Primärschlüsselspalte gleich 1 ist, d. h. der Datensatz wird im B+-Baum gespeichert. Ähnlich verhält es sich bei Aktualisierungsvorgängen: Anstatt den Datensatz direkt zu aktualisieren, wird der alte Datensatz als gelöscht markiert und ein neuer Datensatz erstellt.

Wann werden die alten Versionsdatensätze eigentlich gelöscht?

InnoDB verwendet Undo-Logs, um alte Versionen zu löschen. Dieser Vorgang wird als Bereinigungsvorgang bezeichnet. InnoDB öffnet einen Bereinigungsthread, um Bereinigungsvorgänge auszuführen, und kann die Anzahl der Bereinigungsthreads steuern. Jeder Bereinigungsthread führt alle 10 Sekunden einen Bereinigungsvorgang aus.

InnoDB-Undo-Log-Design

Die Undo-Protokolle mehrerer Transaktionen dürfen auf einer Seite vorhanden sein und die Speicherreihenfolge der Undo-Protokolle ist beliebig. InnoDB verwaltet eine verknüpfte Verlaufsliste, die die Undo-Protokolle in der Reihenfolge verbindet, in der die Transaktionen festgeschrieben wurden.

Während des Bereinigungsvorgangs findet die InnoDB-Speicher-Engine zuerst den ersten Datensatz, der aus der Verlaufsliste bereinigt werden muss, in diesem Fall trx1. Nach der Bereinigung sucht die InnoDB-Speicher-Engine weiter nach Datensätzen, die auf der Rückgängig-Seite, auf der sich trx1 befindet, bereinigt werden können. Hier wird die Transaktion trx3 gefunden und dann trx5, aber es wird festgestellt, dass trx5 von anderen Transaktionen referenziert wird und nicht bereinigt werden kann. Daher wird erneut in der Verlaufsliste gesucht und festgestellt, dass der letzte Datensatz trx2 ist. Dann wird die Rückgängig-Seite gefunden, auf der sich trx2 befindet, und trx6 und trx4 werden nacheinander bereinigt. Da alle Datensätze auf Rückgängig-Seite2 bereinigt wurden, kann die Rückgängig-Seite wiederverwendet werden.

Der Entwurfsmodus der InnoDB-Speicher-Engine, die zuerst in der Verlaufsliste nach Undo-Protokollen und dann auf der Undo-Seite nach Undo-Protokollen sucht, besteht darin, eine große Anzahl zufälliger Lesevorgänge zu vermeiden und so die Effizienz der Bereinigung zu verbessern.

3 InnoDB-Wiederherstellungsvorgänge

3.1 Regeln und Prüfpunkte zum Leeren von Datenseiten

Daten im Speicher (Pufferpool), die nicht auf die Festplatte geschrieben wurden, werden als „schmutzige Daten“ bezeichnet. Da sowohl Daten als auch Protokolle in Form von Seiten vorliegen, stellen schmutzige Seiten schmutzige Daten und schmutzige Protokolle dar.

In InnoDB ist Checkpoint die einzige Regel zum Übertragen von Daten auf die Festplatte. Nachdem der Prüfpunkt ausgelöst wurde, werden die fehlerhaften Daten im Speicher auf die Festplatte geschrieben.

Es gibt zwei Arten von Prüfpunkten in der InnoDB-Speicher-Engine:

• Scharfer Kontrollpunkt: Wenn Sie eine Redo-Logdatei wiederverwenden (z. B. beim Wechseln der Logdateien), werden alle im Redo-Log aufgezeichneten fehlerhaften Daten auf die Festplatte geschrieben.
• Fuzzy-Checkpoint: Es wird immer nur ein kleiner Teil des Protokolls auf einmal auf die Festplatte geschrieben, anstatt alle fehlerhaften Protokolle auf die Festplatte zu schreiben. Die folgenden Situationen lösen diesen Prüfpunkt aus:
  

Prüfpunkt des Master-Threads. Gesteuert durch den Master-Thread wird jede Sekunde oder alle 10 Sekunden ein bestimmter Prozentsatz schmutziger Seiten auf die Festplatte geschrieben.
Prüfpunkt „flush_lru_list“. Ab MySQL 5.6 kann die Variable innodb_page_cleaners verwendet werden, um die Anzahl der Seitenbereinigungs-Threads anzugeben, die für das Leeren von schmutzigen Seiten auf die Festplatte verantwortlich sind. Der Zweck dieses Threads besteht darin, sicherzustellen, dass in der LRU-Liste freie Seiten verfügbar sind.
asynchroner/synchroner Flush-Checkpoint. Synchrones oder asynchrones Leeren der Festplatte. Wenn es beispielsweise noch viele schmutzige Seiten gibt, die nicht auf die Festplatte geleert wurden (wie viele zu viele sind, wird durch ein Verhältnis gesteuert), dann entscheiden wir uns dafür, sie synchron auf die Festplatte zu spülen, aber das passiert selten; wenn es nicht viele schmutzige Seiten gibt, können wir uns dafür entscheiden, sie asynchron auf die Festplatte zu spülen; wenn es nur wenige schmutzige Seiten gibt, können wir die schmutzigen Seiten vorübergehend nicht auf die Festplatte spülen
Schmutzige Seite, zu viele Prüfpunkte. Bei zu vielen schmutzigen Seiten wird ein Prüfpunkt ausgelöst, um sicherzustellen, dass im Cache genügend freier Speicherplatz vorhanden ist. Das Verhältnis „zu viel“ wird durch die Variable innodb_max_dirty_pages_pct gesteuert. Der Standardwert von MySQL 5.6 beträgt 75, was bedeutet, dass, wenn schmutzige Seiten 75 % des Pufferpools belegen, einige schmutzige Seiten zwangsweise auf die Festplatte geleert werden müssen.

Da das Leeren schmutziger Seiten eine gewisse Zeit in Anspruch nimmt, wird die Position des Datensatzprüfpunkts nach Abschluss jedes Leerens im Redo-Protokoll markiert.

3.2 LSN

3.2.1 LSN-Konzept

LSN wird als logische Sequenznummer des Protokolls bezeichnet und belegt in InnoDB 8 Bytes.

Über LSN können wir folgende Informationen erfahren:

• Versionsinformationen der Datenseite.
• Die Gesamtzahl der geschriebenen Protokolle.
• Der Standort des Kontrollpunkts.

LSNs sind an den folgenden zwei Standorten vorhanden:

• In den Redo-Log-Aufzeichnungen.
• Im Kopf jeder Datenseite gibt es eine Variable fil_page_lsn , um den endgültigen LSN-Wert dieser Seite aufzuzeichnen.

Wenn der LSN-Wert auf der Seite kleiner ist als der LSN-Wert im Redo-Protokoll, bedeutet dies offensichtlich, dass Daten verloren gegangen sind.

Mit show engine innodb status können Sie die aktuellen InnoDB-Betriebsinformationen anzeigen. Darin befindet sich eine Spalte „log“ mit Datensätzen zu lsn.

• Die Protokollsequenznummer zeichnet die LSN im aktuellen Redo-Protokoll (im Puffer) auf.
• Das Protokoll wurde bis hierher geleert und entspricht der LSN in der auf die Festplatte geleerten Redo-Protokolldatei.
• „Seiten, auf die geleert wurde“ ist die LSN, die auf die Datenträgerdatenseite geleert wurde.
• letzter Kontrollpunkt bei ist die LSN des letzten Kontrollpunktstandorts.

3.2.2 LSN-Verarbeitungsablauf

(1) Ändern Sie zunächst die Datenseite im Speicher und zeichnen Sie die LSN auf der Datenseite auf, die wir data_in_buffer_lsn nennen.

(2) Wenn die Datenseite (fast gleichzeitig) geändert wird, wird das Redo-Log in den Redo-Log-In-Puffer geschrieben und die entsprechende LSN aufgezeichnet, die temporär „redo_log_in_buffer_lsn“ genannt wird.

(3) Nachdem das Protokoll in den Puffer geschrieben wurde und mehrere Regeln zum Leeren des Protokolls ausgelöst werden, wird das Redo-Protokoll in die Redo-Protokolldatei auf der Festplatte geleert und die entsprechende LSN in der Datei aufgezeichnet, die vorübergehend als redo_log_on_disk_lsn bezeichnet wird.

(4) Datenseiten können nicht für immer im Speicher verbleiben. In einigen Fällen wird ein Prüfpunkt ausgelöst, um schmutzige Seiten im Speicher (schmutzige Datenseiten und schmutzige Protokollseiten) auf die Festplatte zu spülen. Wenn das Spülen schmutziger Seiten am Prüfpunkt abgeschlossen ist, wird daher die LSN-Position des Prüfpunkts im Redo-Protokoll aufgezeichnet, das vorübergehend checkpoint_lsn genannt wird.

(5) Um den Prüfpunktstandort schnell aufzuzeichnen, müssen Sie nur ein Flag setzen. Das Leeren von Datenseiten kann jedoch nicht schnell erfolgen. Beispielsweise müssen an diesem Prüfpunkt viele Datenseiten geleert werden. Das heißt, es dauert eine gewisse Zeit, alle Datenseiten zu leeren. Jede in der Mitte geleerte Datenseite zeichnet die LSN der aktuellen Seite auf, die vorübergehend als data_page_on_disk_lsn bezeichnet wird.

In der obigen Abbildung stellen die horizontalen Linien von oben nach unten dar: die Zeitleiste, die auf der Datenseite im Puffer aufgezeichnete LSN (data_in_buffer_lsn), die auf der Datenseite auf der Festplatte aufgezeichnete LSN (data_page_on_disk_lsn), die im Redo-Protokoll im Puffer aufgezeichnete LSN (redo_log_in_buffer_lsn), die in der Redo-Protokolldatei auf der Festplatte aufgezeichnete LSN (redo_log_on_disk_lsn) und die im Prüfpunkt aufgezeichnete LSN (checkpoint_lsn).

Angenommen, zu Beginn (12:0:00) wurden alle Protokollseiten und Datenseiten auf die Festplatte geschrieben und die Prüfpunkt-LSN aufgezeichnet. Zu diesem Zeitpunkt sind ihre LSNs vollständig konsistent.

Angenommen, eine Transaktion wird gestartet und sofort ein Aktualisierungsvorgang ausgeführt. Nach Abschluss der Ausführung zeichnen sowohl die Datenseite im Puffer als auch das Redo-Protokoll den aktualisierten LSN-Wert auf, der als 110 angenommen wird. Wenn Sie zu diesem Zeitpunkt „show engine innodb status“ ausführen, um die Werte jeder LSN anzuzeigen, dh den Positionsstatus bei ① in der Abbildung, lautet das Ergebnis:

Protokollsequenznummer (110) > Protokoll geleert bis (100) = Seiten geleert bis = letzter Prüfpunkt bei

Danach wird eine weitere Löschanweisung ausgeführt und die LSN erhöht sich auf 150. Um 12:00:01 wird die Regel zum Leeren des Redo-Logs ausgelöst (eine der Regeln ist, dass die durch innodb_flush_log_at_timeout gesteuerte Standardfrequenz zum Leeren des Logs 1 Sekunde beträgt). Zu diesem Zeitpunkt wird die LSN in der Redo-Log-Datei auf der Festplatte auf dieselbe LSN wie die LSN im Redo-Log im Puffer aktualisiert, sodass beide gleich 150 sind. Zu diesem Zeitpunkt wird der InnoDB-Status der Engine angezeigt, der sich in der Abbildung an Position ② befindet. Das Ergebnis ist:

Protokollsequenznummer (150) = Protokoll geleert bis > Seiten geleert bis (100) = letzter Prüfpunkt bei

Danach wird eine Aktualisierungsanweisung ausgeführt und die LSN im Cache wird auf 300 erhöht, was Position ③ in der Abbildung entspricht.

Angenommen, später tritt ein Prüfpunkt auf, der die Position ④ in der Abbildung darstellt. Wie bereits erwähnt, löst der Prüfpunkt das Leeren von Datenseiten und Protokollseiten auf die Festplatte aus, es dauert jedoch eine gewisse Zeit, bis dies abgeschlossen ist. Daher ist die LSN des Prüfpunkts vor Abschluss des Leerens der Datenseiten immer noch die LSN des vorherigen Prüfpunkts, aber zu diesem Zeitpunkt hat sich die LSN der Datenseiten und Protokollseiten auf der Festplatte erhöht, d. h.:

Protokollsequenznummer > Protokoll geleert bis und Seiten geleert bis > letzter Prüfpunkt bei

Die Größe des geleerten Protokolls und der geleerten Seiten lässt sich jedoch nicht ermitteln, da das Leeren des Protokolls schneller, gleich oder langsamer als das Leeren der Daten sein kann. Der Checkpoint-Mechanismus verhindert jedoch, dass die Datenfestplatte langsamer geleert wird als die Protokollfestplatte: Wenn die Leerungsgeschwindigkeit der Datenfestplatte die Leerungsgeschwindigkeit der Protokollfestplatte überschreitet, wird die Leerung der Datenfestplatte vorübergehend gestoppt, bis der Leerungsfortschritt der Protokollfestplatte den Leerungsfortschritt der Datenfestplatte überschreitet.

Wenn die Datenseiten und Protokollseiten auf die Festplatte geschrieben werden, d. h. wenn sie Position ⑤ erreichen, sind alle LSNs gleich 300.

Im Laufe der Zeit wird um 12:00:02, also an Position ⑥ in der Abbildung, die Regel zum Leeren des Protokolls erneut ausgelöst. Allerdings stimmen die Protokoll-LSN im Puffer und die Protokoll-LSN auf der Festplatte zu diesem Zeitpunkt überein, sodass das Leeren des Protokolls nicht durchgeführt wird. Das heißt, wenn zu diesem Zeitpunkt „show engine innodb status“ ausgeführt wird, sind alle LSNs gleich.

Anschließend wird eine Insert-Anweisung ausgeführt. Angenommen, die LSN im Puffer steigt auf 800, was Position ⑦ in der Abbildung entspricht. Zu diesem Zeitpunkt sind die Größen der verschiedenen LSNs dieselben wie in Position ①.

Anschließend wird die Commit-Aktion ausgeführt, also Position ⑧. Standardmäßig lösen Commit-Aktionen eine Protokollleerung, jedoch keine Datenleerung aus. Daher lautet das Ergebnis von „show engine innodb status“:

Protokollsequenznummer = Protokoll geleert bis > Seiten geleert bis = letzter Prüfpunkt bei

Schließlich erscheint im Laufe der Zeit erneut der Kontrollpunkt (Position ⑨ in der Abbildung). Dieser Prüfpunkt löst jedoch keine Protokolllöschung aus, da die LSN des Protokolls vor dem Auftreten des Prüfpunkts synchronisiert wurde. Nehmen Sie an, dass die Daten extrem schnell auf die Festplatte geschrieben werden, so schnell, dass dies in einem Augenblick abgeschlossen ist und die Statusänderung nicht erfasst werden kann. In diesem Fall ist das Ergebnis von „show engine innodb status“, dass alle LSNs gleich sind.

3.3 InnoDB-Wiederherstellungsverhalten

Wenn Sie InnoDB starten, wird unabhängig vom Grund für die letzte Beendigung ein Wiederherstellungsvorgang ausgeführt.

Ein Prüfpunkt zeigt an, dass die LSN auf der Datenseite auf der Festplatte vollständig gelöscht wurde, sodass bei der Wiederherstellung nur der Protokollteil ab dem Prüfpunkt wiederhergestellt werden muss. Dies geschieht beispielsweise, wenn die Datenbank abstürzt, während die LSN des letzten Prüfpunkts 10.000 beträgt und die Transaktion sich im festgeschriebenen Zustand befindet. Beim Starten der Datenbank wird die LSN der Datenseite auf der Festplatte überprüft. Wenn die LSN der Datenseite kleiner ist als die LSN im Protokoll, wird die Wiederherstellung vom Prüfpunkt aus gestartet.

Es gibt eine weitere Situation, in der der Prüfpunkt vor dem Absturz auf die Festplatte geschrieben wird und der Fortschritt beim Schreiben der Datenseite den Fortschritt beim Schreiben der Protokollseite übersteigt. Wenn der Computer zu diesem Zeitpunkt abstürzt, ist die auf der Datenseite aufgezeichnete LSN größer als die LSN auf der Protokollseite. Diese Situation wird während des Wiederherstellungsprozesses des Neustarts überprüft. Zu diesem Zeitpunkt wird der Teil, der den Protokollfortschritt überschreitet, nicht wiederholt, da dies selbst bedeutet, dass das, was getan wurde, nicht wiederholt werden muss.

Darüber hinaus ist das Transaktionsprotokoll idempotent, sodass mehrere Vorgänge, die zum selben Ergebnis führen, nur einmal im Protokoll aufgezeichnet werden. Das Binärprotokoll ist jedoch nicht idempotent. Es werden mehrere Vorgänge aufgezeichnet. Während der Wiederherstellung werden die Aufzeichnungen im Binärprotokoll mehrfach ausgeführt, was wesentlich langsamer ist. Wenn beispielsweise der Anfangswert der ID in einem bestimmten Datensatz 2 ist und der Wert durch Aktualisierung auf 3 und dann wieder auf 2 gesetzt wird, zeichnet das Transaktionsprotokoll die unveränderte Seite auf und es ist keine Wiederherstellung erforderlich. Die Binärdatei zeichnet jedoch die beiden Aktualisierungsvorgänge auf, und diese beiden Aktualisierungsvorgänge werden auch während der Wiederherstellung ausgeführt, was langsamer ist als die Wiederherstellung des Transaktionsprotokolls.

Dies ist das Ende dieses Artikels über Redo-Log und Undo-Log in MySQL. Weitere Informationen zu Redo-Log und Undo-Log 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!