Protokollierung MySQL-Protokollierungsmodul

Empfohlenes kostenloses Lernen: MySQL-Video-Tutorial

Inhaltsverzeichnis

2. Redo-Log

4. Interner Workflow

MySQL-Lernspalte

---

1. Detaillierte Erklärung der MySQL-Infrastruktur und des Algorithmus

3. Aktivieren Sie Binlog-Protokolle in MySQL5.7 und ein einfaches Beispiel für die Datenwiederherstellung

1. Einführung

MySQL verfügt über zwei wichtige Protokollmodule:

redo log (Redo-Protokoll)

und binlog (Archivprotokoll).

Redo-Protokoll ist das Protokoll der InnoDB-Speicher-Engine-Schicht, und Binlog ist das Protokoll, das von der MySQL-Server-Schicht aufgezeichnet wird. Beide sind Protokolle, die bestimmte Vorgänge aufzeichnen, aber die Formate der Datensätze sind unterschiedlich.

2. Redo-Log

Redo-Log: Auch bekannt als (Redo-Log)-Datei, die zum Aufzeichnen von Änderungen in Transaktionsvorgängen verwendet wird Die Transaktion wird übermittelt

.

Im Falle eines Medienfehlers kann die Redo-Log-Datei hilfreich sein. Wenn die Datenbank ausgeschaltet ist, verwendet die InnoDB-Speicher-Engine das Redo-Log, um den Zeitpunkt vor dem Ausschalten wiederherzustellen, um die Integrität der Daten sicherzustellen .

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.

Die InnoDB-Engine aktualisiert diesen Vorgangsdatensatz zum richtigen Zeitpunkt auf der Festplatte. Diese Aktualisierung wird normalerweise abgeschlossen, wenn das System relativ inaktiv ist, um die Aktualisierungseffizienz zu verbessern. Dabei handelt es sich um

WAL

d. h.

Write-Ahead-Logging

Der entscheidende Punkt ist, dass zuerst das Protokoll und dann auf die Festplatte geschrieben wird. Das Redo-Protokoll von InnoDB hat eine feste Größe. Es kann beispielsweise als Satz von 4 Dateien konfiguriert werden und die Größe jeder Datei beträgt 1 GB. Dann können insgesamt 4 GB Vorgänge aufgezeichnet werden. Das Redo-Protokoll beginnt mit dem Schreiben von Anfang an, schreibt bis zum Ende und kehrt dann zum Anfang zurück, um in einer Schleife zu schreiben, wie in der folgenden Abbildung dargestellt.

write pos

ist die Position des aktuellen Datensatzes. Nach dem Schreiben wird an das Ende der Datei Nr. 3 zurückgekehrt.

Prüfpunkt

ist die aktuelle Position, die gelöscht werden soll, und er bewegt sich auch rückwärts und führt eine Schleife durch. Vor dem Löschen des Datensatzes muss der Datensatz in der Datendatei aktualisiert werden. Der ungenutzte Teil zwischen

write pos und check point

kann zum Aufzeichnen neuer Vorgänge verwendet werden.

Wenn write pos

den

Check-Point einholt, bedeutet dies, dass der Redo-Log-Datensatz zu diesem Zeitpunkt nicht voll ist. Sie müssen zunächst anhalten und einige Datensätze löschen, um den Check-Point voranzutreiben . Mit dem Redo-Log kann InnoDB sicherstellen, dass zuvor übermittelte Datensätze nicht verloren gehen, auch wenn die Datenbank abnormal startet. Diese Funktion wird als „absturzsicher“ bezeichnet.

Warum Redo-Log verwenden? Wenn wir DML-Vorgänge in der Datenbank ausführen und das ausgeführte SQL direkt auf die Festplatte schreiben, hat der Druck beim Schreiben von Daten auf die Festplatte einen gewissen Einfluss. Wenn wir den Vorgang einfügen, Wenn die Datenmenge auf einer Seite der Blattknoten nicht ausreicht, muss ein Paging-Algorithmus verwendet werden, der weniger effizient ist.

Wenn ich Redo-Log verwende, schreibe ich zuerst unsere DML-Operationen hinein Führen Sie das Protokoll durch eine „Übertragungsstation“ und geben Sie es dann weiter, wenn ich einen freien Kontrollpunkt habe. Schreiben Sie es auf die Festplatte. Die Effizienz ist viel höher. MySQL-Einstellungen Redo Log

• Die Größe von innodb_log_buffer_size beim Schreiben: (Standard 8M)
• innodb_log_file_size Die Größe der Redo-Log-Datei.
• innodb_log_files_in_group gibt die Anzahl der Dateien in der Redo-Log-Dateigruppe an. Der Standardwert ist 2.
• innodb_mirrored_log_groups gibt die Anzahl der Protokollspiegeldateigruppen an. Der Standardwert ist 1 Der Standardwert ist ./ und gibt die Daten im Datenbankverzeichnis an.
• innodb_flush_log_at_trx_commit So leeren Sie das Protokoll im Protokollpuffer in die Protokolldatei, wenn Sie das Commit festlegen (Wert 0, 1, 2). Standardwert 1

3. binlog

Redo-Log ist ein einzigartiges Protokoll der InnoDB-Engine, und die Serverschicht verfügt auch über ein eigenes Protokoll namens

binlog (archiviertes Protokoll). Warum gibt es zwei Protokolle?

Weil es zu Beginn keine InnoDB-Engine in MySQL gab. Die eigene Engine von MySQL ist MyISAM, aber MyISAM verfügt nicht über Absturzsicherungsfunktionen und Binlog-Protokolle können nur zur Archivierung verwendet werden.

InnoDB wurde von einem anderen Unternehmen in Form eines Plug-Ins in MySQL eingeführt. Da es nicht über die Absturzsicherheitsfunktion verfügt, wenn man sich nur auf Binlog verlässt, verwendet InnoDB ein anderes Protokollsystem, nämlich das Redo-Log, um den

Absturz zu erreichen. sichere Fähigkeit.

Diese beiden Protokolle weisen die folgenden drei Unterschiede auf.

Redo-Log ist einzigartig für die InnoDB-Engine; binlog wird von der Serverschicht von MySQL implementiert und kann von allen Engines verwendet werden.

Redo-Protokoll ist ein physisches Protokoll, das aufzeichnet „
• Welche Änderungen wurden auf einer bestimmten Datenseite vorgenommen
• “; binlog ist ein logisches Protokoll, das die ursprüngliche Logik dieser Anweisung aufzeichnet, wie zum Beispiel „Give ID= 2 Fügen Sie 1" zum c-Feld dieser Zeile hinzu. Redo-Log wird in einer Schleife geschrieben und der Speicherplatz wird immer belegt; Binlog kann zusätzlich geschrieben werden. „Schreiben anhängen“ bedeutet, dass die Binlog-Datei nach Erreichen einer bestimmten Größe zur nächsten wechselt und das vorherige Protokoll nicht überschreibt.
• 4. Interner Workflow

Nehmen Sie die Update-Anweisung einer Tabelle als Beispiel, um einen Blick auf den internen Workflow des Executors und der InnoDB-Engine zu werfen:

mysql> update T set c=c+1 where ID=2;

Wie in der Abbildung unten gezeigt, der Leuchtkasten zeigt an, dass es sich in InnoDB befindet. Ausgeführt, das dunkle Kästchen zeigt an, dass es im Executor ausgeführt wird:

Der Executor sucht zuerst nach der Engine, um die Zeilen-ID = 2 zu erhalten. Die ID ist der Primärschlüssel, und die Engine verwendet direkt die Baumsuche, um diese Zeile zu finden. Wenn sich die Datenseite, auf der sich die Zeile ID=2 befindet, bereits im Speicher befindet, wird sie direkt an den Executor zurückgegeben. Andernfalls muss sie von der Festplatte in den Speicher gelesen und dann zurückgegeben werden.

Der Executor ruft die von der Engine bereitgestellten Zeilendaten ab, addiert 1 zu diesem Wert, zum Beispiel war er früher N, aber jetzt ist er N+1, ruft eine neue Datenzeile ab und ruft dann die Engine-Schnittstelle auf Schreiben Sie diese neue Datenzeile.
• Die Engine aktualisiert diese neue Datenzeile im Speicher und zeichnet den Aktualisierungsvorgang im Redo-Log auf. Zu diesem Zeitpunkt befindet sich das Redo-Log im Vorbereitungszustand. Informieren Sie dann den Testamentsvollstrecker darüber, dass die Ausführung abgeschlossen ist und die Transaktion jederzeit eingereicht werden kann.
• Der Executor generiert das Binlog dieses Vorgangs und schreibt das Binlog auf die Festplatte.
• Der Executor ruft die Commit-Transaktionsschnittstelle der Engine auf, und die Engine ändert das gerade geschriebene Redo-Protokoll in den Commit-Status, und die Aktualisierung ist abgeschlossen.
• Die letzten drei Schritte scheinen etwas „zirkulär“ zu sein. Das Schreiben des Redo-Logs ist in zwei Schritte unterteilt: Vorbereiten und Festschreiben. Tatsächlich handelt es sich hierbei um ein „Zwei-Phasen-Festschreiben“.

Warum benötigt das Protokoll „

zweiphasiges Commit“? Dies kann durch einen Widerspruchsbeweis erklärt werden.

Da Redo-Log und Binlog zwei unabhängige Logiken sind, muss, wenn keine zweistufige Übermittlung erforderlich ist, entweder zuerst das Redo-Log und dann das Binlog geschrieben werden oder die umgekehrte Reihenfolge übernommen werden. Lassen Sie uns am Beispiel der vorherigen Update-Anweisung sehen, welche Probleme bei diesen beiden Methoden auftreten.

Angenommen, der Wert von Feld c in der aktuellen Zeile mit ID = 2 ist 0, und es wird außerdem angenommen, dass während der Ausführung der Aktualisierungsanweisung nach dem Schreiben des ersten Protokolls ein Absturz auftritt, bevor das zweite Protokoll geschrieben wird wird passieren? Wolltuch? 1.

Schreiben Sie zuerst das Redo-Protokoll und dann das Binlog

.

Angenommen, der MySQL-Prozess startet abnormal neu, wenn das Redo-Log geschrieben wird, aber bevor das Binlog geschrieben wird. Nachdem das Redo-Protokoll geschrieben wurde, können die Daten auch bei einem Systemabsturz wiederhergestellt werden. Daher beträgt der Wert von c in dieser Zeile nach der Wiederherstellung 1.

Aber da das Binlog vor seiner Fertigstellung abstürzte, wurde diese Aussage zu diesem Zeitpunkt nicht im Binlog aufgezeichnet. Wenn das Protokoll später gesichert wird, wird diese Anweisung daher nicht in das gespeicherte Binlog aufgenommen.

Dann werden Sie feststellen, dass, wenn Sie dieses Binlog zum Wiederherstellen der temporären Bibliothek verwenden müssen, die temporäre Bibliothek dieses Mal nicht aktualisiert wird, da das Binlog dieser Anweisung verloren geht. Der Wert von c in der wiederhergestellten Zeile ist 0 ist derselbe wie der der Originalbibliothek. Die Werte sind unterschiedlich.

2.Schreiben Sie zuerst das Binlog und dann das Redo-Log. Wenn es nach dem Schreiben des Binlogs zu einem Absturz kommt, ist die Transaktion nach der Wiederherstellung nach dem Absturz ungültig, da das Redo-Log noch nicht geschrieben wurde, sodass der Wert von c in dieser Zeile 0 ist.

Aber das Protokoll „Change c from 0 to 1“ wurde im Binlog aufgezeichnet. Wenn daher später Binlog zum Wiederherstellen verwendet wird, wird eine weitere Transaktion ausgegeben. Der Wert von c in der wiederhergestellten Zeile ist 1, was sich vom Wert in der ursprünglichen Datenbank unterscheidet.

Sie können sehen, dass, wenn „Zwei-Phasen-Commit“ nicht verwendet wird, der Status der Datenbank möglicherweise nicht mit dem Status der mithilfe ihres Protokolls wiederhergestellten Bibliothek übereinstimmt.

Verwandte kostenlose Lernempfehlungen: MySQL-Datenbank(Video)

Das obige ist der detaillierte Inhalt vonProtokollierung MySQL-Protokollierungsmodul. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!