MySQL Master-Slave-Synchronisation, Implementierungsprinzip des Transaktions-Rollbacks

BinLog

BinLog ist ein Binärprotokoll, das alle Änderungen an der Struktur von Datenbanktabellen (wie Erstellen, Ändern der Tabelle) und Änderungen an Tabellendaten (Einfügen, Aktualisieren, Löschen) aufzeichnet. BinLog-Dateien werden für die Master-Slave-Datenbanksynchronisierung verwendet. BinLog-Protokolldateien haben drei Modi.

STATEMENT-Modus

Inhalt: Binlog zeichnet nur die SQL-Anweisungen auf, die Datenänderungen verursachen

Vorteile: Da in diesem Modus keine tatsächlichen Daten aufgezeichnet werden, sind das Protokollvolumen und der E/A-Verbrauch sehr gering und die Leistung optimal.

Nachteile: Einige Vorgänge sind jedoch nicht sicher. Beispielsweise generiert die Funktion uuid() zufällig eine eindeutige Kennung. Wenn Sie sich auf die Binlog-Wiedergabe verlassen, müssen sich die von diesem Vorgang generierten Daten von den Originaldaten unterscheiden, was zu unvorhersehbaren Folgen führen kann.

ROW-Modus

Inhalt: In diesem Modus zeichnet Binlog die Quelldaten und geänderten Zieldaten jeder Operation auf. StreamSets erfordert diesen Modus.

Vorteile: Es kann Daten mit absoluter Genauigkeit wiederherstellen und so die Datensicherheit und -zuverlässigkeit gewährleisten. Die Replikations- und Datenwiederherstellungsprozesse können gleichzeitig durchgeführt werden.

Nachteile: Der Nachteil besteht darin, dass das Binlog-Volumen sehr groß ist. Gleichzeitig ist der Leistungsverbrauch während der Aufzeichnung bei Vorgängen mit vielen geänderten Datensätzen und großen Feldlängen sehr schwerwiegend. Zum Auslesen der Daten sind zudem spezielle Anweisungen erforderlich.

MIXED-Modus

Inhalt: Es handelt sich um eine Kombination der beiden oben genannten Modi: STATEMENT und ROW.

Details: Für die meisten Operationen wird STATEMENT zum Aufzeichnen von Binärprotokollen verwendet. Nur die folgenden Operationen werden mit ROW implementiert: Die Tabellenspeicher-Engine ist NDB, unsichere Funktionen wie uuid() werden verwendet, Einfügeverzögerungsanweisungen werden verwendet und temporäre Tabellen werden verwendet

Master-Slave-Synchronisationsprozess:

1. Der Masterknoten muss die binäre Protokollierung aktivieren, um alle Ereignisse aufzuzeichnen, die Datenbankdaten ändern.

2. Der Slave-Knoten startet einen Thread (I/O-Thread), um als MySQL-Client zu fungieren, und fordert Ereignisse in der Binärprotokolldatei des Master-Knotens über das MySQL-Protokoll an.

3. Der Masterknoten startet einen Thread (Dump-Thread), um die Ereignisse in seinem eigenen Binärprotokoll zu überprüfen und sie mit der von der anderen Partei angeforderten Position zu vergleichen. Wenn kein Anforderungspositionsparameter vorhanden ist, sendet der Masterknoten das erste Ereignis in der ersten Protokolldatei nacheinander an den Slaveknoten.

4. Der Slave-Knoten empfängt die vom Master-Knoten gesendeten Daten und platziert sie in der Relay-Protokolldatei. Und notieren Sie den spezifischen Speicherort, an welche Binärprotokolldatei des Masterknotens die Anforderung gesendet wurde (im Masterknoten befinden sich mehrere Binärdateien).

5. Starten Sie einen anderen Thread (SQL-Thread) vom Knoten aus, lesen Sie die Ereignisse im Relay-Protokoll und führen Sie sie erneut lokal aus.

Der Standardreplikationsmodus von MySQL ist asynchron und verfügt über parallele Replikationsfunktionen. Die Master-Datenbank sendet das Protokoll an die Slave-Datenbank und ignoriert es dann. Dies führt zu einem Problem. Wenn die Master-Datenbank abstürzt und die Slave-Datenbank nicht verarbeitet werden kann, geht das Protokoll verloren, nachdem die Slave-Datenbank zur Master-Datenbank hochgestuft wurde. Daraus ergeben sich zwei Konzepte.

• Vollständig synchrone Replikation
  

Nachdem die Master-Datenbank das Binärprotokoll geschrieben hat, wird die Synchronisierung des Protokolls mit der Slave-Datenbank erzwungen. Nachdem alle Slave-Datenbanken die Ausführung abgeschlossen haben, wird das Protokoll an den Client zurückgegeben. Es ist jedoch offensichtlich, dass diese Methode die Leistung erheblich beeinträchtigt.

• Halbsynchrone Replikation

Die Logik der halbsynchronen Replikation besteht darin, dass die Slave-Datenbank nach dem erfolgreichen Schreiben des Protokolls eine ACK-Bestätigung an die Master-Datenbank zurücksendet. Die Master-Datenbank betrachtet den Schreibvorgang als abgeschlossen, wenn sie eine Bestätigung von mindestens einer Slave-Datenbank erhält.

RedoLog

Der Unterschied zwischen Binlog und Redolog:

• Redo-Log ist spezifisch für die InnoDB-Engine; Binlog ist auf der Serverebene von MySQL implementiert und kann von allen Engines verwendet werden.
• Das Redo-Protokoll ist ein physisches Protokoll, das aufzeichnet, welche Änderungen an einer Datenseite vorgenommen wurden. Das Binärprotokoll ist ein logisches Protokoll, das die ursprüngliche Logik der Anweisung aufzeichnet, z. B. das Hinzufügen von 1 zum Feld c der Zeile mit der ID=2.
• Das Redo-Protokoll wird zyklisch geschrieben, und der Speicherplatz ist irgendwann erschöpft. Das Binärprotokoll kann in angehängter Form geschrieben werden. Anhängendes Schreiben bedeutet, dass, nachdem die Binlog-Datei eine bestimmte Größe erreicht hat, zur nächsten gewechselt wird und das vorherige Protokoll nicht überschrieben wird.

Wenn in MySQL jeder Aktualisierungsvorgang auf die Festplatte geschrieben werden muss und die Festplatte auch den entsprechenden Datensatz finden und ihn dann aktualisieren muss, sind die E/A- und Suchkosten des gesamten Prozesses sehr hoch. Schreiben Sie zuerst das Protokoll und dann das BinLog und das RedoLog auf der Festplatte.

1. Wenn ein Datensatz aktualisiert wird, schreibt die InnoDB-Engine den Datensatz zuerst in RedoLog und aktualisiert den Speicher. Gleichzeitig aktualisiert die InnoDB-Engine den Operationsdatensatz im Leerlauf auf der Festplatte.

2. Wenn zu viele Updates für RedoLog vorhanden sind, müssen Sie zuerst einige RedoLog-Daten auf die Festplatte schreiben und dann einige RedoLog-Daten löschen.

RedoLog schreibt POS und Checkpoint

RedoLog hat Schreibposition und Checkpoint

Schreibposition: ist die Position des aktuellen Datensatzes. Beim Schreiben bewegt er sich rückwärts. Nach dem Schreiben bis zum Ende von Datei Nr. 3 kehrt er zum Anfang von Datei Nr. 0 zurück.

Prüfpunkt: verkürzt die Wiederherstellungszeit der Datenbank. Wenn der Pufferpoolplatz nicht ausreicht, werden die schmutzigen Seiten auf die Festplatte geschrieben. Wenn Redolog nicht verfügbar ist, werden die schmutzigen Seiten geschrieben.

Beim sequentiellen Schreiben des Redo-Logs werden tatsächlich mehrere feste Dateien in einer Schleife geschrieben und nach Abschluss einer Runde von Anfang an überschrieben. Es umfasst zwei Positionen: Prüfpunkt und Schreibposition. Schreibposition ist die zu schreibende Position, die in der Schleife erhöht wird. Prüfpunkt ist die aktuelle Position, die gelöscht werden soll. Der Raum zwischen den beiden ist beschreibbar. Wenn die Schreibposition den Prüfpunkt erreicht, wird die Aktualisierung gestoppt, einige Datensätze überschrieben und dann mit dem Schreiben des Redo-Protokolls fortgefahren.

Absturzsicheres Redo-Log

MySQL unterstützt Benutzer bei der Anpassung der Art und Weise, wie Protokolle beim Commit im Protokollpuffer in die Protokolldatei geleert werden. Diese Steuerung wird durch den Wert der Variable innodb_flush_log_at_trx_commit bestimmt. Diese Variable hat drei Werte: 0, 1, 2 und der Standardwert ist 1. Beachten Sie jedoch, dass diese Variable nur steuert, ob die Commit-Aktion den Protokollpuffer auf die Festplatte schreibt.

• Wenn der Wert auf 1 gesetzt ist, wird bei jedem Festschreiben einer Transaktion das Protokoll im Protokollpuffer in den Betriebssystempuffer geschrieben und fsync() aufgerufen, um es in die Protokolldatei auf der Festplatte zu schreiben. Bei dieser Methode gehen auch bei einem Systemabsturz keine Daten verloren, da jedoch jede Übermittlung auf die Festplatte geschrieben wird, ist die E/A-Leistung schlecht.
• Wenn dieser Wert auf 0 gesetzt ist, werden Protokolle im Protokollpuffer nicht in den Betriebssystempuffer geschrieben, wenn die Transaktion festgeschrieben wird. Stattdessen werden Protokolle jede Sekunde in den Betriebssystempuffer geschrieben und fsync() wird aufgerufen, um sie in die Protokolldatei auf der Festplatte zu schreiben. Das heißt, wenn der Wert auf 0 gesetzt ist, werden die auf die Festplatte geschriebenen Daten (ungefähr) jede Sekunde aktualisiert. Bei einem Systemabsturz gehen 1 Sekunde Daten verloren.
• Wenn der Wert auf 2 gesetzt ist, wird jedes Commit nur in den Betriebssystempuffer geschrieben und dann wird jede Sekunde fsync() aufgerufen, um das Protokoll im Betriebssystempuffer in die Protokolldatei auf der Festplatte zu schreiben.

Um die Persistenz und Konsistenz von Transaktionen in der Master-Slave-Replikationsstruktur sicherzustellen, müssen protokollbezogene Variablen wie folgt festgelegt werden:

• Wenn die binäre Protokollierung aktiviert ist, setzen Sie sync_binlog=1, was bedeutet, dass jede Transaktion synchron auf die Festplatte geschrieben wird.
• Setzen Sie innodb_flush_log_at_trx_commit immer auf 1, d. h. jede Transaktion wird bei jedem Commit auf die Festplatte geschrieben.

Die Einstellungen der beiden oben genannten Variablen stellen sicher, dass jede Transaktion in das Binärprotokoll und das Transaktionsprotokoll geschrieben und beim Festschreiben auf die Festplatte geleert wird.

Mit dem Redo-Log kann InnoDB sicherstellen, dass selbst bei einem abnormalen Neustart der Datenbank zuvor übermittelte Datensätze nicht verloren gehen. Diese Funktion wird als absturzsicher bezeichnet. Zweiphasiges Redolog-Commit: Um die Logik zwischen Binlog und Redolog konsistent zu machen. Der Einreichungsprozess läuft wie folgt ab:

1 Phase vorbereiten --> 2 Binärprotokoll schreiben --> 3 Commit

1. Wenn der Prozess vor Schritt 2 abstürzt, wird festgestellt, dass nach dem Neustart kein Commit erfolgt und der Prozess zurückgesetzt wird. Sichern und Wiederherstellen: kein Binärprotokoll. Konsistenz
2. Wenn der Absturz vor Schritt 3 auftritt, stellt die Neustartwiederherstellung fest, dass zwar kein Commit vorliegt, die Vorbereitung und das Binärprotokoll jedoch abgeschlossen sind, sodass das Commit nach dem Neustart automatisch ausgeführt wird. Backup: mit Binlog. Konsistent

UndoLog

Undo-Log hat zwei Funktionen: Rollback und Multiple Row Version Control (MVCC). Es wird hauptsächlich in zwei Typen unterteilt

Wenn Daten geändert werden, wird nicht nur das Wiederherstellen aufgezeichnet, sondern auch das entsprechende Rückgängigmachen. Wenn die Transaktion aus irgendeinem Grund fehlschlägt oder zurückgesetzt wird, kann sie mithilfe des Rückgängigmachens zurückgesetzt werden. Wenn ein Datensatz gelöscht wird, wird ein entsprechender Einfügedatensatz im Rückgängig-Protokoll aufgezeichnet und umgekehrt. Wenn ein Datensatz aktualisiert wird, wird ein entsprechender entgegengesetzter Aktualisierungsdatensatz aufgezeichnet.

Wenn ein Rollback ausgeführt wird, kann der entsprechende Inhalt aus dem logischen Datensatz im Undo-Protokoll gelesen und zurückgerollt werden.

• Undo-Protokoll einfügen
  

Stellt das Undo-Protokoll dar, das generiert wird, wenn eine Transaktion einen neuen Datensatz einfügt. Es wird nur benötigt, wenn die Transaktion zurückgesetzt wird, und kann sofort nach dem Festschreiben der Transaktion verworfen werden.

• Undo-Protokoll aktualisieren
  

Das Undo-Protokoll wird generiert, wenn eine Transaktion aktualisiert oder gelöscht wird. Es wird nicht nur benötigt, wenn die Transaktion zurückgesetzt wird, sondern auch, wenn der Snapshot gelesen wird. Daher kann es nicht einfach so gelöscht werden. Nur wenn das schnelle Lesen oder das Zurücksetzen der Transaktion das Protokoll nicht betrifft, wird das entsprechende Protokoll gleichmäßig vom Bereinigungsthread gelöscht.

Oben finden Sie ausführliche Informationen zum Implementierungsprinzip der MySQL-Master-Slave-Synchronisierung und des Transaktions-Rollbacks. Weitere Informationen zur MySQL-Master-Slave-Synchronisierung und zum Transaktions-Rollback finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!