Spezielle Anordnung von MySQL-Protokollen: Redo-Log und Undo-Log

Dieser Artikel vermittelt Ihnen relevantes Wissen über MySQL. Das MySQL-Protokoll zeichnet die täglichen Vorgänge und Fehlerinformationen der MySQL-Datenbank auf (jedes speichert unterschiedliche Protokolltypen, die Sie abfragen können). Schauen wir uns den Betriebsstatus, Benutzervorgänge, Fehlermeldungen usw. an. Ich hoffe, dass es für alle hilfreich ist.

Empfohlenes Lernen: MySQL-Video-Tutorial

Redo-Log

REDO LOG wird als Redo-Log bezeichnet. Wenn der MySQL-Server unerwartet abstürzt oder ausfällt, stellt es sicher, dass übermittelte Transaktionen auf der Festplatte gespeichert bleiben (Persistenz). .

InnoDB verarbeitet Datensätze in Seiteneinheiten. Durch Hinzufügen, Löschen, Ändern und Abfragen wird die gesamte Seite in den Pufferpool geladen (Festplatte -> Speicher). Der Änderungsvorgang in der Transaktion ändert nicht direkt die Daten auf der Festplatte Ändern Sie es zunächst. Die Daten im Pufferpool im Speicher werden vom Hintergrundthread in regelmäßigen Abständen asynchron auf der Festplatte aktualisiert.

Pufferpool: Er kann Indizes und Daten speichern, das Lesen und Schreiben beschleunigen, Datenseiten direkt im Speicher bearbeiten und verfügt über einen dedizierten Thread zum Schreiben schmutziger Seiten im Pufferpool auf die Festplatte.

Warum ändern Sie die Daten auf der Festplatte nicht direkt?

Denn wenn Sie die Festplattendaten direkt ändern, werden die geänderten Daten an verschiedenen Orten auf der Festplatte verteilt und müssen daher hin und her gesucht werden. Daher ist die Trefferquote niedrig und der Verbrauch hoch Eine kleine Änderung muss die gesamte Seite ersetzen.

Im Gegensatz dazu werden die Daten auf der Festplatte auf einen Teil der Festplatte verteilt, sodass der Suchvorgang und die Suchzeit entfallen wird gespeichert.

Die Verwendung von Hintergrundthreads zum Aktualisieren der Festplatte mit einer bestimmten Häufigkeit kann die Häufigkeit zufälliger E/A verringern und den Durchsatz erhöhen. Dies ist der Hauptgrund für die Verwendung des Pufferpools.

Das Problem der Änderung des Speichers und der anschließenden asynchronen Synchronisierung mit der Festplatte:

Da der Pufferpool ein Bereich im Speicher ist, können bei einem unerwarteten Systemabsturz einige fehlerhafte Daten möglicherweise nicht aktualisiert werden Die Festplatte wird rechtzeitig gelöscht und die Haltbarkeit der Transaktion kann nicht gewährleistet werden. Daher wurde Redo-Log eingeführt. Beim Ändern von Daten wird ein zusätzliches Protokoll aufgezeichnet, das zeigt, dass sich der xx-Offset der Seite xx um xx geändert hat. Wenn das System abstürzt, kann es anhand des Protokollinhalts wiederhergestellt werden.

Der Unterschied zwischen dem Schreiben von Protokollen und dem direkten Aktualisieren der Festplatte besteht darin: Das Schreiben von Protokollen erfolgt durch Anhängen des Schreibens, sequentielle E/A, schneller und der geschriebene Inhalt ist relativ kleiner.

Das Redo-Protokoll besteht aus zwei Teilen:

1. Redo-Log-Puffer (Speicherebene , Standard 16M, kann über den Parameter innodb_log_buffer_size geändert werden)
2. Redo-Protokolldatei (persistent, Festplattenebene)

Der allgemeine Prozess des Änderungsvorgangs:

Schritt 1: Lesen Sie zuerst die Originaldaten von der Festplatte in den Speicher, ändern Sie die Speicherkopie der Daten und generieren Sie schmutzige 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: Standardmäßig in der Transaktion Aktualisieren Sie nach der Übermittlung den Inhalt des Redo-Log-Puffers in der Redo-Log-Datei und verwenden Sie das Anhängen, um in die Redo-Log-Datei zu schreiben

Schritt 4: Aktualisieren Sie regelmäßig die geänderten Daten im Speicher auf der Festplatte (hier sprechen wir).

Das allgemein als Write-Ahead-Protokoll (Pre-Log-Persistenz) bezeichnete Protokoll bezieht sich auf das Beibehalten der entsprechenden Protokollseite im Speicher vor dem Beibehalten einer Datenseite.

Vorteile des Redo-Logs:

• Reduziert die Häufigkeit der Festplattenaktualisierungen.
• Redo-Log nimmt nur wenig Platz ein.
• Nicht unbedingt, dies hängt von der Redo-Log-Flushing-Strategie ab, da sich der Redo-Log-Puffer auch im Speicher befindet, wenn nach der Übermittlung der Transaktion der Redo-Log-Puffer keine Zeit hatte, die Daten zur Persistenz in der Redo-Log-Datei zu aktualisieren Zu diesem Zeitpunkt gehen im Falle eines Ausfalls immer noch Daten verloren. Wie kann man es lösen? Sweep-Strategie.

Redo-Log-Flush-Strategie

InnoDB bietet drei Strategien für den Parameter innodb_flush_log_at_trx_commit, um zu steuern, wann der Redo-Log-Puffer in die Redo-Log-Datei geleert wird:

Der Wert ist 0: Starten Sie einen Hintergrundthread und leeren Sie ihn alle auf die Festplatte 1s, beim Festschreiben einer Transaktion ist keine Aktualisierung erforderlich

Der Wert ist 1: Beim Festschreiben wird eine synchrone Aktualisierung durchgeführt (Standardwert), was die Haltbarkeit der Daten wirklich gewährleistet

Der Wert ist 2: Beim Festschreiben ist dies der Fall Nur im Betriebssystem-Kernel-Pufferbereich aktualisiert, ist der genaue Zeitpunkt des Festplattenleerens ungewiss.
• Der Fall, in dem der Wert 0 ist:

Da es ein Intervall von 1 Sekunde gibt, geht 1 Sekunde Daten verloren schlimmster Fall. Der Fall, in dem

Wert 1 ist:

Beim Festschreiben müssen Sie den Redo-Log-Puffer aktiv in der Redo-Log-Datei aktualisieren. Wenn der Computer auf halbem Weg abstürzt, schlägt die Transaktion ohne Verlust fehl. Dies kann die Haltbarkeit der Transaktion wirklich gewährleisten. Am schlechtesten ist jedoch die Effizienz.

Wenn der Wert 2 ist: Er wird basierend auf dem Betriebssystem bestimmt.

Kann auf 0 oder 2 angepasst werden, um die Transaktionsleistung zu verbessern, aber die ACID-Eigenschaften gehen verloren.

Andere Parameter

• innodb_log_group_home_dir: Geben Sie den Pfad an, in dem sich die Redo-Log-Dateigruppe befindet liegt im Datenverzeichnis der Datenbank. Im Standarddatenverzeichnis von MySQL gibt es zwei Dateien mit den Namen ib_logfile0 und ib_logfile1. Die Protokolle im Protokollpuffer werden standardmäßig in diese beiden Festplattendateien geschrieben.
• innodb_log_files_in_group: Gibt die Anzahl der Redo-Log-Dateien an. Die Benennungsmethode lautet wie folgt: ib_logfile0, iblogfile1 ... iblogfilen. Der Standardwert ist 2, der Höchstwert ist 100.
• innodb_log_file_size: Legen Sie die Größe einer einzelnen Redo-Log-Datei fest. Der Standardwert ist 48 MB.

Rückgängig-Protokoll

Undo-Protokoll wird verwendet, um die Atomizität und Konsistenz von Transaktionen sicherzustellen. Es hat zwei Funktionen: ① Bereitstellung eines Rollback-Vorgangs ② Multiversionskontrolle MVVC

Rollback-Vorgang

Wie bereits im Redo-Log erwähnt, aktualisiert der Hintergrundthread von Zeit zu Zeit die Daten im Pufferpool auf der Festplatte Während dieser Zeit treten verschiedene Fehler (Ausfallzeiten) auf oder es werden Rollback-Anweisungen ausgeführt. Anschließend müssen die zuvor ausgeführten Vorgänge zurückgesetzt werden, um die Atomizität sicherzustellen. Das Rückgängig-Protokoll ermöglicht ein Rollback der Transaktion.

MVVC

Wenn eine gelesene Zeile durch eine andere Transaktion gesperrt wird, kann die vorherige in der Zeile aufgezeichnete Datenversion aus dem Rückgängig-Protokoll analysiert werden, sodass Benutzer die Daten vor dem aktuellen Transaktionsvorgang lesen können – – Snapshot-Lesen.

Snapshot-Lesen: Die von SQL gelesenen Daten sind die historische Version, es ist keine Sperre erforderlich, normales SELECT ist das Snapshot-Lesen.

Komponenten des Rückgängig-Protokolls:

• Beim Einfügen eines Datensatzes muss der Primärschlüsselwert des Datensatzes aufgezeichnet werden, damit die Daten beim Rollback gelöscht werden können.
• Beim Aktualisieren von Datensätzen müssen alle geänderten alten Werte aufgezeichnet und dann beim Zurücksetzen auf die alten Werte aktualisiert werden.
• Beim Löschen müssen alle Datensätze aufgezeichnet werden und die Datensätze des Inhalts müssen beim Zurücksetzen erneut eingefügt werden.

Durch den Auswahlvorgang wird kein Rückgängig-Protokoll generiert. Nach MySQL5.5 gibt es insgesamt 128 Rollback-Segmente. Das heißt, es können insgesamt 128 * 1024 Rückgängig-Vorgänge aufgezeichnet werden.

Jede Transaktion verwendet nur ein Rollback-Segment und ein Rollback-Segment kann mehrere Transaktionen gleichzeitig bedienen.

Das Rückgängig-Protokoll kann nicht sofort nach der Übermittlung der Transaktion gelöscht werden. Einige Transaktionen möchten möglicherweise die vorherige Datenversion lesen (Snapshot-Lesen). Wenn eine Transaktion festgeschrieben wird, wird das Rückgängig-Protokoll daher in eine verknüpfte Liste eingefügt, die als Versionskette bezeichnet wird. Ob das Rückgängig-Protokoll gelöscht wird oder nicht, wird von einem Thread namens „purge“ beurteilt.

Undo-Typ

Undo-Protokoll ist unterteilt in:

Einfügungs-Rückgängig-Protokoll

Da die Aufzeichnung des Einfügevorgangs nur für die Transaktion selbst und nicht für andere Transaktionen sichtbar ist (dies ist eine Anforderung der Transaktionsisolation), also das Rückgängigmachen Das Protokoll kann direkt nach dem Festschreiben der Transaktion gelöscht werden. Es ist kein Spülvorgang erforderlich.

Rückgängig-Protokoll aktualisieren

Rückgängig-Protokoll aktualisieren zeichnet das Rückgängig-Protokoll auf, das durch Lösch- und Aktualisierungsvorgänge generiert wird. Das Rückgängig-Protokoll muss möglicherweise einen MVCC-Mechanismus bereitstellen, sodass es beim Festschreiben der Transaktion nicht gelöscht werden kann. 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.

Der Lebenszyklus des Rückgängig-Protokolls

Angenommen, es gibt zwei Werte, A=1 und B=2, und dann ändert eine Transaktion A in 3 und B in 4. Der Änderungsprozess kann wie folgt vereinfacht werden:

1. begin

2.Record A=1, um das Protokoll rückgängig zu machen

3.Update A=3

4.Record A=3, um das Protokoll zu wiederholen

5.Record B=2, um das Protokoll rückgängig zu machen
6.Update B=4
7.Record B =4 zum Redo-Log
8. Redo-Log auf Festplatte aktualisieren
9.commit



Wenn das System in einem der Schritte 1-8 ausfällt und die Transaktion nicht übermittelt wird, hat die Transaktion keine Auswirkung auf die Daten auf die Festplatte.

Wenn es zwischen 8 und 9 ausfällt, können Sie nach der Wiederherstellung ein Rollback durchführen oder die Transaktionsübermittlung fortsetzen, da das Redo-Protokoll zu diesem Zeitpunkt beibehalten wurde.

• Wenn das System nach 9 ausfällt und die in der Speicherzuordnung geänderten Daten keine Zeit hatten, wieder auf die Festplatte zurückgeschrieben zu werden, können die Daten nach der Wiederherstellung des Systems gemäß dem Redo-Log wieder auf die Festplatte zurückgeschrieben werden.

Detaillierter Generierungsprozess

Für die InnoDB-Engine verfügt jeder Zeilendatensatz zusätzlich zu den Daten des Datensatzes selbst auch über mehrere ausgeblendete Spalten:

DB_ROW_ID∶Die Primärschlüssel-ID des Datensatzes.

DB_TRX_ID: Transaktions-ID. Wenn ein Datensatz geändert wird, wird die ID der Transaktion aufgezeichnet.

• DB_ROLL_PTR: Rollback-Zeiger, Zeiger in der Versionskette.

Wenn wir INSERT ausführen:

begin;
INSERT INTO user (name) VALUES ('tom');

Die eingefügten Daten generieren ein Einfüge-Rückgängig-Protokoll und der Rollback-Zeiger der Daten zeigt darauf. Das Rückgängig-Protokoll zeichnet die Seriennummer des Rückgängig-Protokolls, die Spalte und den Wert des eingefügten Primärschlüssels auf. Wenn dann ein Rollback durchgeführt wird, können die entsprechenden Daten direkt über den Primärschlüssel gelöscht werden.

Wenn wir UPDATE ausführen:

Update-Rückgängig-Protokoll wird für den Aktualisierungsvorgang generiert und in diejenigen unterteilt, die den Primärschlüssel aktualisieren, und diejenigen, die den Primärschlüssel nicht aktualisieren. Angenommen, wir führen jetzt Folgendes aus:

UPDATE user SET name='Sun' WHERE id=1;

Zu diesem Zeitpunkt wird das neue Protokoll generiert. Der Rückgängig-Protokolldatensatz wird zur Versionskette hinzugefügt, seine Rückgängig-Nummer ist 1 und der Rollback-Zeiger des neuen Rückgängig-Protokolls zeigt auf das alte Rückgängig-Protokoll ( rückgängig machen (nr=0).

Angenommen, Sie führen jetzt Folgendes aus:

UPDATE user SET id=2 WHERE id=1;

Für den Vorgang zum Aktualisieren des Primärschlüssels wird zuerst das Löschmarkierungsflag für die ursprünglichen Daten geöffnet. Die tatsächliche Löschung erfolgt zu diesem Zeitpunkt nicht Der Reinigungsthread wird beurteilt und dann in Wenn später ein neues Datenelement eingefügt wird, generieren die neuen Daten auch ein Rückgängig-Protokoll und die Sequenznummer des Rückgängig-Protokolls erhöht sich.

Sie können feststellen, dass jede Änderung an Daten ein Rückgängig-Protokoll generiert. Wenn ein Datensatz mehrmals geändert wird, werden mehrere Rückgängig-Protokolle erstellt. Das Rückgängig-Protokoll zeichnet das Protokoll vor der Änderung auf und die Sequenznummer erhöht sich Wenn Sie also ein Rollback durchführen möchten, gehen Sie entsprechend der Sequenznummer vorwärts, um unsere Originaldaten zu finden.

Wie das Rückgängig-Protokoll zurückgesetzt wird

Im obigen Beispiel sollte unter der Annahme, dass ein Rollback ausgeführt wird, der entsprechende Prozess wie folgt aussehen:

1 Löschen Sie die Daten mit der ID=2 über das Protokoll von Undo-Nr.=3

2 . Stellen Sie die Löschmarkierung der Daten mit der ID=1 auf 0 über das Protokoll von Undo-Nr.=2 wieder her. Stellen Sie den Namen der Daten mit der ID=1 für Tom über das Protokoll von Undo-Nr.=1 wieder her der Daten mit der ID=1 an Tom durch Undo No=. Das Protokoll von 0 löscht die Daten mit der ID=1 Datei, auch Änderungsprotokoll (Update-Protokoll) genannt. Es zeichnet alle von der Datenbank ausgeführten Aktualisierungsanweisungen auf.

Hauptanwendungsszenarien von Binlog:

Datenwiederherstellung: Wenn MySQL unerwartet stoppt, kann das Protokoll zur Wiederherstellung und Sicherung verwendet werden.

Datenreplikation: Der Master überträgt sein Binärprotokoll an Slaves, um eine Master-Slave-Datenkonsistenz zu erreichen

show variables like '%log_bin%';

Sehen Sie sich das Bin-Log-Protokoll an:

mysqlbinlog -v "/var/lib/mysql/binlog/xxx.000002"

Verwenden Sie das Protokoll, um Daten wiederherzustellen:

mysqlbinlog [option] filename|mysql –uuser -ppass;

Löschen Sie das Binär-Log:

PURGE {MASTER | BINARY} LOGS TO ‘指定日志文件名'
PURGE {MASTER | BINARY} LOGS BEFORE ‘指定日期'

Schreibzeitpunkt
• Während der Transaktionsausführung wird das Protokoll zuerst in den Bin-Log-Cache geschrieben Die Transaktion wird übermittelt. Anschließend wird der Binlog-Cache in die Binlog-Datei geschrieben. Da das Binlog einer Transaktion nicht aufgeteilt werden kann, muss es unabhängig von der Größe der Transaktion einmal geschrieben werden, sodass das System jedem Thread einen Speicherblock als Binlog-Cache zuweist.

Vergleich zwischen Binlog und Redo-Log

Redo-Log ist ein physisches Protokoll. Der Datensatzinhalt lautet „xx Änderungen wurden auf xx Datenseite vorgenommen“, das von der InnoDB-Speicher-Engine-Schicht generiert wird.

Das Binlog ist ein logisches Protokoll, und der aufgezeichnete Inhalt ist die ursprüngliche Logik der Anweisung. Es ähnelt dem Hinzufügen von 1 zum c-Feld der Zeile mit der ID = 2, die zur Serviceschicht gehört.

Die beiden Schwerpunkte sind ebenfalls unterschiedlich. Redo-Log gibt InnoDB die Möglichkeit, sich nach Abstürzen zu erholen, und Binlog stellt die Datenkonsistenz der MySQL-Cluster-Architektur sicher.

Zweistufiges Commit

Während der Ausführung der Update-Anweisung werden zwei Protokolle, Redo-Log und Binlog, aufgezeichnet. Basierend auf Basistransaktionen kann das Redo-Log während der Transaktionsausführung kontinuierlich geschrieben werden, während das Binlog nur möglich ist Beim Senden der Transaktion wird geschrieben, daher ist der Schreibzeitpunkt von Redo-Log und Binlog unterschiedlich.

• Die Logik zwischen dem Redo-Log und dem Binlog ist inkonsistent. Welche Probleme werden auftreten?

Nehmen Sie die Update-Anweisung als Beispiel. Nehmen Sie an, dass für den Datensatz mit der ID=2 der Feld-c-Wert 0 ist. Aktualisieren Sie den Feld-c-Wert auf 1. Die SQL-Anweisung ist update T set c=1, wobei id=2 ist.

Angenommen, nachdem das Redo-Protokoll während des Ausführungsprozesses geschrieben wurde, tritt beim Schreiben des Binlog-Protokolls eine Ausnahme auf.

Da das Binlog abnormal ist, bevor es mit dem Schreiben fertig ist, gibt es keine entsprechende Ausnahme Änderungsdatensatz im Binlog zu diesem Zeitpunkt. Wenn daher das Binlog-Protokoll zum Wiederherstellen von Daten verwendet wird oder der Slave später das Binlog des Masters liest, wird diese Aktualisierung weggelassen. Der C-Wert der wiederhergestellten Zeile ist 0 und der C-Wert dieser Zeile in der Originaldatenbank ist 1 zur Redo-Log-Wiederherstellung. Die endgültigen Daten sind inkonsistent.

Um das Problem der logischen Konsistenz zwischen den beiden Protokollen zu lösen, verwendet die InnoDB-Speicher-Engine ein zweiphasiges Commit-Schema. Teilen Sie das Redo-Protokoll in zwei Schritte auf: Vorbereiten und Festschreiben. Dies ist ein zweistufiges Festschreiben.

Lassen Sie die endgültige Übermittlung des Redo-Protokolls und des Bin-Protokolls miteinander verknüpfen. Wie bereits erwähnt, muss das Redo-Protokoll beim Festschreiben einer Transaktion standardmäßig synchronisiert werden, bevor das Festschreiben erfolgreich ist Bin Log verfügt ebenfalls über diese Funktion und stellt sicher, dass keine Daten verloren gehen.

Nach der Verwendung des zweiphasigen Commits hat es keine Auswirkungen, wenn beim Schreiben in das Binlog eine Ausnahme auftritt, da MySQL beim Wiederherstellen von Daten basierend auf dem Redo-Log feststellt, dass sich das Redo-Log noch in der Vorbereitungsphase befindet und es gibt kein entsprechendes Binlog-Protokoll, sodass die Übermittlung fehlschlägt. Setzen Sie die Daten zurück.

In einem anderen Szenario tritt während der Commit-Phase des Redo-Logs eine Ausnahme auf. Wird die Transaktion zurückgesetzt?

führt kein Rollback der Transaktion durch, sondern führt die im obigen Bild dargestellte Logik aus. Obwohl sich das Redo-Protokoll in der Vorbereitungsphase befindet, kann das entsprechende Binlog-Protokoll über die Transaktions-ID gefunden werden, sodass MySQL dies berücksichtigt Die Transaktion muss abgeschlossen sein, um die Daten wiederherzustellen.

Empfohlenes Lernen: MySQL-Video-Tutorial

Das obige ist der detaillierte Inhalt vonSpezielle Anordnung von MySQL-Protokollen: Redo-Log und Undo-Log. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!