Einführung in MySQL-Protokoll, Redo-Protokoll und Binlog

Kostenlose Lernempfehlung: MySQL-Video-Tutorial

Vorwort

Solange Sie ein Programmierer sind, der mit MySQL in Berührung gekommen ist, haben Sie mehr oder weniger davon gehört Redo-Log (starke Protokollierung) und Binlog (Archivprotokoll). Lassen Sie uns heute die Verwendungszwecke und Unterschiede zwischen diesen beiden Protokollen erläutern.

Einfach ausgedrückt ist Redo-Log ein für InnoDB einzigartiges Protokoll. Wenn Sie andere Speicher-Engines verwenden, gibt es kein Redo-Log, sondern nur Binlog.

Binlog ist das Protokoll der Serverschicht von MySQL. Unabhängig davon, welche Speicher-Engine verwendet wird, wird es ein Binlog geben. Warum brauchen wir also Redo-Log und Binlog? Lässt sich nicht alles mit nur einem Binlog lösen? Schauen wir uns als Nächstes den Unterschied zwischen Redo-Log und Binlog genauer an.

Redo-Protokoll

Wenn Sie in MySQL eine Anweisung aktualisieren möchten, müssen Sie Aktualisierungsbedingungen mitbringen, z. B. update T set name = 'god-jiang' where id=6, im Allgemeinen zuerst id= abfragen 6-Anweisung und führen Sie dann den Aktualisierungsvorgang aus.

Wenn die Anzahl der Updates 100, 1.000 oder sogar 10.000 beträgt, muss jedes Update auf die Festplatte geschrieben werden. Dann muss der entsprechende Datensatz auf der Festplatte gefunden und dann aktualisiert werden. Die E/A-Kosten und Suchkosten des gesamten Prozesses sind zu hoch. Um dieses Problem zu lösen, verwendeten die Designer von MySQL die WAL-Technologie. Der vollständige Name von WAL lautet Write Ahead Logging, was bedeutet, dass zuerst das Protokoll geschrieben und dann auf die Festplatte geschrieben wird.

Spezifischer Vorgang: Wenn ein Datensatz aktualisiert werden muss, schreibt die InnoDB-Engine den Datensatz zunächst in das Redo-Protokoll und aktualisiert den Speicher. Zu diesem Zeitpunkt ist die Aktualisierung abgeschlossen. Gleichzeitig aktualisiert die InnoDB-Engine diesen Vorgangsdatensatz zum richtigen Zeitpunkt (wenn das System im Leerlauf ist).

Aber die Größe des Redo-Logs ist festgelegt und es ist unmöglich, die ganze Zeit unendlich zu schreiben. Schauen wir uns an, wie MySQL das macht.

write pos ist die Position des aktuellen Datensatzes, die sich beim Schreiben rückwärts bewegt. Der Prüfpunkt ist die aktuelle zu löschende Position, die sich ebenfalls rückwärts bewegt und umläuft. Vor dem Löschen des Datensatzes muss der Datensatz in der Datendatei aktualisiert werden.

Der grüne Teil zwischen Schreibposition und Kontrollpunkt zeigt an, dass neue Vorgänge erfasst werden können. Wenn die Schreibposition den Prüfpunkt einholt, bedeutet dies, dass das Redo-Protokoll zu diesem Zeitpunkt nicht mehr fortgesetzt werden kann. Sie müssen das Löschen einiger Datensätze stoppen und den Prüfpunkt zurücksetzen.

Mit dem Redo-Log kann InnoDB sicherstellen, dass zuvor übermittelte Transaktionen nicht verloren gehen, selbst wenn die Datenbank eine Ausnahme erkennt und neu startet. Diese Funktion wird auch als „absturzsicher“ bezeichnet. Das Obige ist die Einführung in das Redo-Log. Nachdem Sie dies gelesen haben, können Sie versuchen, die DBA-Kollegen Ihres Unternehmens zu fragen, ob MySQL innerhalb eines halben Monats auf den Stand von jeder Sekunde zurückgesetzt werden kann Dank des Redo-Logs.

binlog

Wenn man MySQL als Ganzes betrachtet, ist es tatsächlich in zwei Schichten unterteilt, eine ist die Serverschicht und die andere ist die Speicher-Engine-Schicht. Das oben besprochene Redo-Protokoll ist ein Protokoll, das nur für die InnoDB-Engine gilt, während das Binlog ein Protokoll ist, das zur Serverschicht gehört und auch als Archivprotokoll bezeichnet wird.

Der Unterschied zwischen Redo-Log und Binlog.

Redo-Log ist einzigartig für die InnoDB-Engine. Binlog wird von der Serverschicht von MySQL implementiert und kann von allen Engines verwendet werden „XXX-Daten „XXX-Änderungen wurden auf der Seite vorgenommen“; Binlog ist ein logisches Protokoll, das die ursprüngliche Logik aufzeichnet, und sein Datensatz ist die entsprechende SQL-Anweisung.

• Redo-Protokoll wird in einer Schleife geschrieben, und der Speicherplatz wird definitiv aufgebraucht sein, daher sind Schreibposition und Prüfpunkt erforderlich. Beim Schreiben wird auf eine bestimmte Größe umgeschaltet und das vorherige Protokoll wird nicht überschrieben Der Executor und die InnoDB-Engine werden über eine einfache Update-Anweisung an den Executor weitergeleitet Geben Sie den Namen in „god-jiang“ ein und rufen Sie dann die Speicher-Engine-Schnittstelle erneut auf, um neue Daten zu schreiben. Die Engine schreibt die neuen Daten in den Speicher und schreibt gleichzeitig den Aktualisierungsvorgang in das Redo-Protokoll Zu diesem Zeitpunkt befindet sich das Redo-Protokoll im Vorbereitungsstatus und schreibt das Binlog auf die Festplatte. Der Executor ruft die Schnittstelle der Engine auf und ändert das soeben geschriebene Redo-Protokoll Commit-Status und die Aktualisierung ist abgeschlossen
• Das entsprechende Flussdiagramm

Warum schreibt das Redo-Log schließlich in den Vorbereitungsstatus und wechselt dann das Binlog in den Commit-Status? Tatsächlich wird dieser Prozess als „zweistufige Einreichung“ bezeichnet.

1. Zwei-Phasen-Commit
2. Tatsächlich können sowohl Redo-Log als auch Binlog verwendet werden, um den Status der Transaktionsübermittlung darzustellen, und zwei-Phasen-Commit dient dazu, die beiden Zustände logisch konsistent zu halten.

3. Zum Beispiel: update T set name = ‚god-jiang‘ where id = 6Was passiert ohne zweiphasiges Commit?

   Schreiben Sie zuerst das Redo-Protokoll und dann das Binlog. Nehmen Sie an, dass nach dem Schreiben des Redo-Protokolls das Binlog noch nicht geschrieben wurde und MySQL zu diesem Zeitpunkt abnormal neu startet. Da das Redo-Protokoll geschrieben wurde, wird beim Wiederherstellen des Systems name='god-jiang' verwendet. Das Binlog wurde jedoch nicht geschrieben, sodass das Binlog diese Anweisung nicht aufzeichnet. Wenn das Binlog zu diesem Zeitpunkt zum Wiederherstellen von Daten verwendet wird, ist der wiederhergestellte Name der ursprüngliche Wert, der sich vom Redo-Log unterscheidet.

   Wenn Sie zuerst Binlog und dann Redo Log schreiben, werden Sie ebenfalls feststellen, dass die von den beiden Protokollen wiederhergestellten Daten unterschiedlich sind. Diese Inkonsistenz führt online zu einer Master-Slave-Inkonsistenz.

   Zusammenfassung

   • Redo-Log kann absturzsichere Funktionen speichern und sicherstellen, dass bei einem abnormalen MySQL-Neustart keine Daten verloren gehen.
   • binlog kann die entsprechenden SQL-Anweisungen aufzeichnen und sicherstellen, dass bei einem abnormalen MySQL-Neustart keine Daten verloren gehen . Die stufenweise Übermittlung kann die logische Konsistenz der Daten aufrechterhalten

   Verwandte kostenlose Lernempfehlungen:

   MySQL-Datenbank(Video)

Das obige ist der detaillierte Inhalt vonEinführung in MySQL-Protokoll, Redo-Protokoll und Binlog. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!