Einführung in häufige Protokollierungsprobleme in MySQL

Dieser Artikel bietet Ihnen eine Einführung in häufige Protokollprobleme in MySQL. Ich hoffe, dass er Ihnen als Referenz dienen wird.

Es gibt zwei Protokolle in MySQL, nämlich: Redo-Protokoll und Archivprotokoll (Binlog). (Empfohlene Kurse: MySQL-Tutorial)

Unter anderem kann Binlog für Standby-Datenbanken verwendet oder zur Wiederherstellung historischer Datenbankdaten gespeichert werden. Es wird auf der Serverebene implementiert und kann von allen Engines gemeinsam genutzt werden. Das Redo-Protokoll ist ein für InnoDB einzigartiges Protokoll und wird zur Unterstützung absturzsicherer Funktionen verwendet.

Sie haben sicher schon von der zweiphasigen Festschreibung von MySQL-Transaktionen gehört, was bedeutet, dass die Transaktion bei der Übermittlung in zwei Phasen unterteilt ist: Vorbereiten und Festschreiben.

Abbildung 1 zeigt den Ausführungsprozess einer Transaktion. In den letzten drei Schritten können Sie sehen, dass zuerst die Redo-Log-Vorbereitung abgeschlossen ist, dann das Binlog geschrieben wird und schließlich die Redo-Log-Commit-Phase beginnt.

Abbildung 1 Zweistufiges Einreichungsdiagramm

Hier möchte ich Ihnen zunächst ein Missverständnis erklären: Handelt es sich bei diesem Bild nicht um die Ausführung eines Updates? Anweisung? Wie kommt es, dass die Commit-Anweisung aufgerufen wird?

Normalerweise haben Sie diese Frage, weil Sie die zwei „Commit“-Konzepte verwechseln:

in der Frage „Commit“. „Anweisung“ bezieht sich auf den Befehl, der zum Festschreiben einer Transaktion in der MySQL-Syntax verwendet wird. Wird im Allgemeinen in Verbindung mit „Begin/Start-Transaktion“ verwendet.

Der in unserem Bild verwendete „Commit-Schritt“ bezieht sich auf einen kleinen Schritt im Transaktionseinreichungsprozess und ist auch der letzte Schritt. Wenn dieser Schritt abgeschlossen ist, wird die Transaktion übermittelt.

Wenn die „Commit-Anweisung“ ausgeführt wird, enthält sie den „Commit-Schritt“.

In unserem Beispiel wird die Transaktion nicht explizit gestartet, daher ist die Update-Anweisung selbst eine Transaktion. Dieser „Commit-Schritt“ wird beim Commit der Transaktion nach Abschluss der Ausführung verwendet.

Als nächstes analysieren wir, was passiert, wenn MySQL zu unterschiedlichen Zeiten während der zweiphasigen Übermittlung abnormal neu startet.

Wenn zum Zeitpunkt A in der Abbildung ein Absturz auftritt, dh nach dem Schreiben des Redo-Protokolls in der Vorbereitungsphase und vor dem Schreiben des Binlogs, wurde das Binlog noch nicht geschrieben. Das Redo-Protokoll wurde noch nicht festgeschrieben. Wenn der Absturz wiederhergestellt ist, wird die Transaktion zurückgesetzt. Zu diesem Zeitpunkt wurde das Binlog noch nicht geschrieben und wird daher nicht in die Standby-Datenbank übertragen. An diesem Punkt können wir alle verstehen.

Wir verstehen, dass Probleme hauptsächlich zum Zeitpunkt B auftreten, wenn das Binlog geschrieben wird und ein Absturz auftritt, bevor das Redo-Log festgeschrieben wird. Wie wird MySQL mit der Wiederherstellung nach einem Absturz umgehen?

Sehen wir uns zunächst die Beurteilungsregeln bei der Wiederherstellung nach einem Unfall an.

1. Wenn die Transaktion im Redo-Log abgeschlossen ist, das heißt, sie hat bereits eine Commit-ID, dann senden Sie sie direkt Vollständige Vorbereitung, dann feststellen, ob das entsprechende Transaktions-Binlog vorhanden und abgeschlossen ist:

a Wenn ja, die Transaktion festschreiben

b.

Hier entspricht der Absturz zum Zeitpunkt B der Situation 2(a) und die Transaktion wird während des Absturzwiederherstellungsprozesses festgeschrieben.

Lassen Sie uns nun die zweistufige Einreichung weiter ausbauen.

Frage 1: Woher weiß MySQL, dass das Binlog vollständig ist?

Antwort: Das Binlog einer Transaktion hat ein vollständiges Format:

Wenn Sie sowohl auf Prepare als auch auf Commit stoßen Senden Sie das Redo-Protokoll direkt.

Wenn Sie auf ein Redo-Protokoll stoßen, das nur Parare, aber kein Commit enthält, gehen Sie mit der XID zum Binlog, um die entsprechende Transaktion zu finden.

Frage 3: Das Redo-Log in der Vorbereitungsphase sowie das komplette Binlog können nach dem Neustart wiederhergestellt werden

Antwort: Diese Frage sollte eigentlich besprochen werden Im Widerspruchsbeweis beziehen sich die erhaltenen Daten auf die Konsistenz der Sicherung. Zum Zeitpunkt B, also nachdem das Binlog geschrieben wurde, stürzt MySQL ab. Zu diesem Zeitpunkt wurde das Binlog geschrieben und wird von der Slave-Bibliothek (oder der mithilfe dieses Binlogs wiederhergestellten Bibliothek) verwendet.

Diese Transaktion muss also auch in der Hauptdatenbank eingereicht werden. Mit dieser Strategie wird garantiert, dass die Daten in der Hauptdatenbank und der Standby-Datenbank konsistent sind.

Frage 4: Wenn dies der Fall ist, warum gibt es eine zweistufige Einreichung? Schreiben Sie einfach zuerst das Redo-Protokoll zu Ende und schreiben Sie dann das Binlog. Bei der Wiederherstellung nach einem Absturz müssen beide Protokolle vollständig sein. Ist es die gleiche Logik?

Antwort: Tatsächlich ist das zweiphasige Commit ein klassisches verteiltes Systemproblem und nicht nur bei MySQL zu finden.

Wenn ich ein Szenario nennen muss, um die Notwendigkeit dieser Maßnahme zu veranschaulichen, dann ist es die Frage der Dauerhaftigkeit der Transaktion.

Für die InnoDB-Engine kann die Transaktion nicht zurückgesetzt werden, wenn das Redo-Log-Commit abgeschlossen ist (wenn dies ein Rollback ermöglicht, werden möglicherweise die Aktualisierungen anderer Transaktionen überschrieben). Und wenn das Redo-Protokoll direkt übermittelt wird und das Binlog dann nicht geschrieben werden kann, kann InnoDB kein Rollback durchführen und die Daten und das Binlog sind inkonsistent.

Die zweistufige Einreichung soll jedem eine Chance geben. Wenn alle sagen: „Mir geht es gut“, reichen Sie gemeinsam ein.

Frage 5: Ohne die Einführung von zwei Protokollen besteht keine Notwendigkeit für eine zweistufige Einreichung. Reicht es nicht aus, binlog nur zur Unterstützung der Wiederherstellung nach einem Absturz und auch zur Unterstützung der Archivierung zu verwenden?

Antwort: Wenn ich diese Frage noch einmal übersetze, bedeutet das, dass nur das Binlog beibehalten wird und der Übermittlungsprozess dann wie folgt geändert werden kann: ... -> „Binlog schreiben“ -> „Transaktion festschreiben“, bietet es auch die Möglichkeit, nach Abstürzen wiederherzustellen?

Die Antwort ist nein.

Wenn es einen historischen Grund gibt, dann ist InnoDB nicht die native Speicher-Engine von MySQL. Die native Engine von MySQL ist MyISAM, die nicht für die Unterstützung der Wiederherstellung nach einem Absturz konzipiert ist.

Bevor InnoDB der MySQL-Engine-Familie als MySQL-Plug-in beitrat, war es bereits eine Engine, die eine Wiederherstellung nach einem Absturz und Transaktionsunterstützung ermöglichte.

Nachdem InnoDB mit MySQL verbunden war, stellte ich fest, dass es besser war, das ursprüngliche Redo-Log von InnoDB zu verwenden, da das Binlog nicht in der Lage war, nach Abstürzen wiederherzustellen.

Und wenn wir über Umsetzungsgründe sprechen, gibt es viele. Wie in der Frage erwähnt, wird zur Implementierung des Absturzwiederherstellungsprozesses nur Binlog verwendet. Ich habe ein schematisches Diagramm gezeichnet und es gibt hier kein Redo-Log.

Abbildung 2 Nur Binlog unterstützt die Wiederherstellung nach einem Absturz

Bei einem solchen Prozess kann Binlog immer noch keine Wiederherstellung nach einem Absturz unterstützen. Lassen Sie mich über einen Punkt sprechen, der nicht unterstützt wird: Binlog verfügt nicht über die Möglichkeit, „Datenseiten“ wiederherzustellen.

Wenn an der markierten Stelle im Bild, also wenn binlog2 geschrieben wurde, aber die gesamte Transaktion noch nicht festgeschrieben wurde, stürzt MySQL ab.

Nach dem Neustart wird die Engine-interne Transaktion 2 zurückgesetzt, und dann kann binlog2 angewendet werden, um sie wiederherzustellen. Bei Transaktion 1 betrachtet das System die Übermittlung jedoch bereits als abgeschlossen und wendet binlog1 nicht erneut an.

Die InnoDB-Engine verwendet jedoch die WAL-Technologie. Bei der Ausführung einer Transaktion wird die Transaktion nach dem Schreiben in den Speicher und das Protokoll abgeschlossen. Wenn es später abstürzt, verlassen Sie sich auf das Protokoll, um die Datenseiten wiederherzustellen.

Das heißt, wenn an dieser Stelle in der Abbildung ein Absturz auftritt, geht möglicherweise auch Transaktion 1 verloren und die Datenseitenebene geht verloren. Zu diesem Zeitpunkt werden die Aktualisierungsdetails der Datenseite nicht im Binlog aufgezeichnet und können nicht wiederhergestellt werden.

Wenn Sie sagen möchten, kann ich den Inhalt des Binlogs optimieren und Änderungen auf der Datenseite aufzeichnen lassen? Ja, aber das ist eigentlich nur die Erstellung eines weiteren Redo-Logs.

Zumindest die aktuelle Binlog-Funktion kann die Wiederherstellung nach einem Absturz nicht unterstützen.

Frage 6: Kann es umgekehrt werden und nur Redo-Log anstelle von Binlog verwendet werden?

Antwort: Aus Sicht der Wiederherstellung nach einem Absturz ist es in Ordnung. Sie können Binlog deaktivieren, sodass kein zweiphasiges Commit erfolgt, das System aber dennoch absturzsicher ist.

Wenn Sie sich jedoch die Nutzungsszenarien verschiedener Unternehmen der Branche ansehen, werden Sie feststellen, dass Binlog in offiziellen Produktionsbibliotheken immer aktiviert ist. Weil Binlog über Funktionen verfügt, die Redo-Log nicht ersetzen kann.

Eine davon ist die Archivierung. Das Redo-Log wird in einer Schleife geschrieben. Wenn Sie bis zum Ende schreiben, müssen Sie zum Anfang zurückkehren und mit dem Schreiben fortfahren. Auf diese Weise kann das historische Protokoll nicht aufbewahrt werden und das Redo-Protokoll kann nicht als Archiv dienen.

Einer ist, dass das MySQL-System auf Binlog basiert. Binlog ist eine Funktion, die MySQL von Anfang an hat und die an vielen Stellen verwendet wird. Die Grundlage für die hohe Verfügbarkeit des MySQL-Systems ist unter anderem die Binlog-Replikation.

Es gibt auch viele Unternehmen mit heterogenen Systemen (z. B. einigen Datenanalysesystemen), und diese Systeme sind darauf angewiesen, MySQL-Binlog zu verwenden, um ihre eigenen Daten zu aktualisieren. Wenn Binlog deaktiviert ist, können diese nachgelagerten Systeme keine Eingaben vornehmen.

Kurz gesagt, da viele Systemmechanismen, einschließlich der Hochverfügbarkeit von MySQL, jetzt auf Binlog basieren, ist das Redo-Log „Dove Occuping the Elster's Nest“ noch nicht möglich. Sie sehen, wie wichtig es ist, eine Ökologie zu entwickeln.

Abschließend empfehle ich Ihnen, auf Ding Qis Kolumne „MySQL Practical Lectures 45“ zu achten. In dieser Spalte hilft Ihnen Ding Qi dabei, die wichtigsten Kenntnisse zum Erlernen von MySQL wie Transaktionen, Indizes, Sperren usw. zu ordnen. Außerdem analysiert und bespricht er mit Ihnen spezifische Probleme, die während des Entwicklungsprozesses häufig auftreten, und hilft Ihnen beim Verständnis die Essenz hinter den Problemen. Sie erhalten detaillierte Erklärungen und Prinzipien der MySQL-Kerntechnologie sowie eine Analyse von 36 häufigen MySQL-Problempunkten. Das Binlog im

Anweisungsformat hat am Ende COMMIT; das Binlog im

Zeilenformat hat am Ende ein XID-Ereignis.

Darüber hinaus wurde nach MySQL Version 5.6.2 auch der Parameter binlog-checksum eingeführt, um die Richtigkeit des Binlog-Inhalts zu überprüfen. Bei Binlog-Protokollen, die aus Festplattengründen möglicherweise Fehler in der Mitte des Protokolls enthalten, kann MySQL dies durch Überprüfung der Prüfsummenergebnisse herausfinden. Daher verfügt MySQL weiterhin über eine Möglichkeit, die Integrität des Transaktions-Binlogs zu überprüfen.

Frage 2: Wie hängen Redo-Log und Binlog zusammen?

Antwort: Sie haben ein gemeinsames Datenfeld namens XID. Während der Wiederherstellung nach einem Absturz wird das Redo-Protokoll in der folgenden Reihenfolge gescannt:

Das obige ist der detaillierte Inhalt vonEinführung in häufige Protokollierungsprobleme in MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!