Was sind die Wissenspunkte des Redo-Logs und des Undo-Logs im MySQL-Log?

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 werden (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 grundlegende Grund 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 (Speicher Ebene, Standard 16 MB, kann über den Parameter innodb_log_buffer_size geändert werden Daten von der Festplatte in den Speicher lesen, die Speicherkopie der Daten ändern und schmutzige Daten generieren

Schritt 2: Erzeugen Sie ein Redo-Protokoll und schreiben Sie es in den Redo-Log-Puffer, wobei Sie den geänderten Wert der Daten aufzeichnen

2. Schritt 3 : Standardmäßig wird der Inhalt des Redo-Log-Puffers nach dem Absenden der Transaktion in die Redo-Log-Datei geleert und die Redo-Log-Datei angehängt und geschrieben.

Schritt 4: Aktualisieren Sie regelmäßig die geänderten Daten im Speicher Die Festplatte (was hier gesagt wird, sind schmutzige Daten, die nicht rechtzeitig vom Hintergrundthread geleert wurden)

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

Vorteile des Redo-Logs:

Reduzierte Festplattenaktualisierungshäufigkeit

Redo-Log nimmt wenig Platz ein

Die Redo-Log-Schreibgeschwindigkeit ist hoch

• Kann Redo-Log definitiv die Haltbarkeit von Transaktionen garantieren?
  Dies hängt nicht unbedingt 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, es ist keine Aktualisierung erforderlich, wenn eine Transaktion übermittelt wird

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

Der Wert ist 2: Wenn Beim Festschreiben wird es nur aktualisiert. Geben Sie den Kernelpuffer des Betriebssystems ein. Die spezifische Spülzeit ist ungewiss. Der Fall, in dem der Wert 0 ist:

• Da es ein Datenintervall von 1 Sekunde und 1 Sekunde gibt gehen im schlimmsten Fall verloren.

Situation, wenn der Wert 1 ist:
• Beim Festschreiben müssen Sie den Redo-Log-Puffer aktiv in der Redo-Log-Datei aktualisieren. Wenn er in der Mitte ausfällt, schlägt die Transaktion fehl und es erfolgt kein Fehler Der Verlust kann wirklich garantiert werden. 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. Der Standardwert ist ./, was bedeutet, dass er sich in den Daten befindet Verzeichnis 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: Geben Sie die Anzahl der Redo-Log-Dateien an, Benennungsmethode wie: ib_logfile0, iblogfile1... iblogfilen. Der Standardwert ist 2, der Höchstwert ist 100.

• Standardmäßig ist die Größe von innodb_log_file_size auf 48 MB eingestellt, was für die Größeneinstellung einer einzelnen Redo-Log-Datei verwendet wird.

Rückgängig-Protokoll

Rückgängig-Protokoll wird verwendet, um die Atomizität und Konsistenz von Transaktionen sicherzustellen. Es hat zwei Funktionen: ① Rollback-Vorgang bereitstellen ② Multiversionskontrolle MVVC

Rollback-Vorgang

Wie bereits im Redo-Log erwähnt, aktualisiert der Hintergrundthread den Puffer von Zeit zu Zeit Wenn jedoch während der Ausführung der Transaktion verschiedene Fehler (Ausfallzeiten) auftreten oder eine Rollback-Anweisung ausgeführt wird, müssen die vorherigen Vorgänge zurückgesetzt werden, um die Atomizität des Rückgängig-Protokolls sicherzustellen Bietet Transaktions-Rollback von.

MVVC

Wenn eine gelesene Zeile durch andere Transaktionen gesperrt wird, kann die vorherige Datenversion des Zeilendatensatzes aus dem Rückgängig-Protokoll analysiert werden, sodass Benutzer Daten zuvor lesen können Der aktuelle Transaktionsvorgang – Snapshot-Lesen.

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

Komponenten des Rückgängig-Protokolls:

• Beim Einfügen eines Datensatzes muss der Primärschlüsselwert des Datensatzes aufgezeichnet werden, damit dies möglich ist Daten werden beim Rollback gelöscht.

• Beim Aktualisieren des Datensatzes müssen alle geänderten alten Werte aufgezeichnet und 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.

Auswahlvorgang generiert kein Rückgängig-Protokoll

Rollback-Segment und Rückgängig-Seite

In der InnoDB-Speicher-Engine , Das Rückgängig-Protokoll verwendet das Rollback-Segment zur Speicherung, und jedes Rollback-Segment enthält 1024 Rückgängig-Protokollsegmente. 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 Löschen des Rückgängig-Protokolls kann nicht unmittelbar nach dem Festschreiben der Transaktion durchgeführt werden, da einige Transaktionen möglicherweise die vorherige Datenversion lesen möchten (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.

Rückgängig-Typ

Das Rückgängig-Protokoll ist unterteilt in:

Rückgängig-Protokoll einfügen

Weil die Aufzeichnung des Einfügevorgangs ist Nur für Die Transaktion selbst ist sichtbar, für andere Transaktionen jedoch nicht sichtbar (dies ist eine Voraussetzung für die Transaktionsisolation), sodass das Rückgängig-Protokoll direkt nach dem Festschreiben der Transaktion gelöscht werden kann. Es ist kein Spülvorgang erforderlich.

Rückgängig-Protokoll aktualisieren

Rückgängig-Protokolle zeichnen die Änderungen auf, die an Lösch- und Aktualisierungsvorgängen vorgenommen wurden. Um den MVCC-Mechanismus zu unterstützen, kann das Rückgängig-Protokoll nicht sofort gelöscht werden, wenn die Transaktion festgeschrieben wird. Fügen Sie es beim Senden zur Rückgängig-Protokollliste hinzu 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. Die Der Änderungsprozess kann wie folgt vereinfacht werden:

1.begin

2. Rekord A=1, um das Protokoll rückgängig zu machen
3.update A=3
4 . Zeichnen Sie A=3 auf, um das Protokoll
5 zu wiederholen. Nehmen Sie B=4 auf, um das Protokoll
8 rückgängig zu machen. Aktualisieren Sie das Redo-Protokoll auf der Festplatte
9.commit

Wenn das System in einem der Schritte 1–8 ausfällt, ist die Transaktion nicht erfolgt Diese Transaktion hat keine Auswirkungen auf die Daten auf der Festplatte.

• Wenn der Wert zwischen 8 und 9 sinkt, können Sie nach der Wiederherstellung ein Rollback durchführen oder mit der vollständigen Transaktionsübermittlung fortfahren, da das Redo-Protokoll dies getan hat wurde zu diesem Zeitpunkt beibehalten.

• Wenn das System nach 9 ausfällt und die in der Speicherzuordnung geänderten Daten nicht zurück auf die Festplatte geschrieben werden, können die Daten nach der Wiederherstellung des Systems wiederhergestellt werden gemäß Redo-Log auf die Festplatte zurückgespült.

Detaillierter Generierungsprozess

Für die InnoDB-Engine wird jede Zeile außer Zusätzlich aufgezeichnet Zu den Daten des Datensatzes selbst gibt es mehrere versteckte 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');

Jedes Mal, wenn Daten eingefügt werden, wird ein Rückgängig-Protokoll des Einfügevorgangs erstellt, und der Rollback-Zeiger der Daten zeigt auf dieses Protokoll. 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:

Beim Ausführen eines Aktualisierungsvorgangs wird ein Update-Rückgängig-Protokoll generiert, einschließlich zweier Fälle, in denen der Primärschlüssel aktualisiert und der Primärschlüssel nicht aktualisiert wird. Angenommen, der Aktualisierungsvorgang wird jetzt ausgeführt:

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

Zu diesem Zeitpunkt wird der neue Rückgängig-Protokolldatensatz zur Versionskette hinzugefügt, seine Rückgängig-Nummer ist 1 und der Rollback-Zeiger des neuen Rückgängig-Protokolls zeigt darauf das alte Undo-Protokoll (Undo-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 Beurteilen Sie den Reinigungsthread und fügen Sie dann später neue Daten ein. Die neuen Daten generieren 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. So wird das Rückgängig-Protokoll zurückgesetzt . 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

MySQL MVVC-Parallelitätskontrolle für mehrere Versionen

Erweiterung

Bin-Protokoll

Binärprotokoll, auch als Update bekannt log ist eine Art Protokolldatei im Binärformat, die an einer Datenbank vorgenommene Änderungen aufzeichnet. 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 übergibt sein Binärprotokoll an Slaves, um Master-Slave-Daten zu erhalten Konsistenz

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ärprotokoll:

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

  Schreibzeitpunkt

• Während der Transaktionsausführung wird das Protokoll zuerst in das Bin-Log geschrieben Cache und Transaktion Schreiben Sie beim Senden den Binlog-Cache in die Binlog-Datei. 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
Das von der InnoDB-Speicher-Engine-Schicht generierte Redo-Log ist ein physisches Protokoll, das verwendet wird, um aufzuzeichnen, „welche Änderungen an welchen Datenseiten vorgenommen wurden“.
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 lautet update T set c=1, wobei die ID=2 ist.
Angenommen, nach dem Schreiben des Redo-Protokolls während der Ausführung tritt beim Schreiben des Binlog-Protokolls eine Ausnahme auf.

Da die Binlog-Ausnahme das Schreiben unterbricht, gibt es keinen entsprechenden Änderungsdatensatz. Wenn das Binlog-Protokoll zum Wiederherstellen von Daten verwendet wird oder der Slave das Binlog des Masters liest, wird diese Aktualisierung daher weggelassen. Der C-Wert der wiederhergestellten Zeile ist 0, und der C-Wert dieser Zeile in der Originaldatenbank ist 1 Die Redo-Log-Wiederherstellung ist inkonsistent.



InnoDB-Speicher-Engine verwendet ein zweistufiges Festschreibungsschema, um das Problem der logischen Konsistenz zwischen den beiden Protokollen zu lösen. Die zweistufige Übermittlung bezieht sich auf die Aufteilung des Redo-Protokolls in zwei Schritte: Vorbereiten und Festschreiben.

Lassen Sie die endgültige Übermittlung des Redo-Protokolls und des Bin-Protokolls miteinander verknüpfen. Wenn eine Transaktion festgeschrieben wird, muss das Redo-Protokoll 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, denn wenn MySQL Daten basierend auf dem Redo-Log wiederherstellt, stellt es fest, 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.

Das obige ist der detaillierte Inhalt vonWas sind die Wissenspunkte des Redo-Logs und des Undo-Logs im MySQL-Log?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!