Wie implementiert die MySQL-Datenbank die XA-Spezifikation?

MySQL-Konsistenzprotokoll

Was passiert mit nicht festgeschriebenen Transaktionen, wenn die MySQL-Datenbank einen Stromausfall hat?

Antwort: Verlassen Sie sich auf Protokolle.

Denn bevor eine Operation ausgeführt wird, schreibt die Datenbank zunächst den Inhalt der Operation in das Dateisystemprotokoll und führt dann die Operation aus. Wenn das System abstürzt oder die Stromversorgung unterbricht, wird das Protokoll vor dem Vorgang geschrieben, auch wenn der Vorgang nicht abgeschlossen ist. Daher können wir die Wiederherstellung immer noch auf Grundlage des Protokollinhalts durchführen.

In der MySQL InnoDB-Engine beziehen sich das Redo-Protokoll, das Rollback-Protokoll und das Binärprotokoll auf die Konsistenz.

Redo-Protokoll

Immer wenn eine Operation ausgeführt wird, wird die entsprechende Operation in das Redo-Protokoll geschrieben, bevor die Daten tatsächlich geändert werden. Auf diese Weise können Sie diese Änderungen auch nach der Wiederherstellung des Systems fortsetzen, wenn ein unerwarteter Stromausfall oder ein anderer Unfall eintritt und die Ausführung nachfolgender Aufgaben unmöglich macht.

Undo-Protokoll

Entsprechend dem Redo-Log, auch Undo-Log genannt, zeichnet es den Zustand der Daten vor Beginn der Transaktion auf.

Wenn einige Änderungen aufgrund einer unerwarteten Situation nicht abgeschlossen werden können, kann der Zustand vor den Änderungen anhand des Undo-Protokolls wiederhergestellt werden.

Beispielsweise aktualisiert die Transaktion T1 die Daten X und führt eine Aktualisierungsoperation für X aus, wodurch sie von 10 auf 20 aktualisiert werden. Das entsprechende Redo-Protokoll ist <T1, X, 20> und das Undo-Protokoll ist <T1, X, 10>.

binlog

Es handelt sich um ein Binärprotokoll, das von der MySQL-Serverebene verwaltet wird. Es ist eines der wichtigsten Protokolle von MySQL. Es zeichnet alle DDL- und DML-Anweisungen auf, einschließlich der Ausführungszeit von Anweisungen, zusätzlich zu Datenabfrageanweisungen wie „Select“ und „Show“.

Binlog unterscheidet sich vom Redo/Undo-Log in der InnoDB-Engine. Sein Hauptzweck ist Replikation und Wiederherstellung. Es wird verwendet, um SQL-Anweisungen aufzuzeichnen, die MySQL-Daten aktualisieren oder potenziell aktualisieren, und sie in Form von Transaktionsprotokollen auf der Festplatte zu speichern.

Binlog wird hauptsächlich im Master-Slave-Replikationsprozess von MySQL verwendet. Der MySQL-Cluster startet Binlog auf der Masterseite. Der Master übergibt sein Binärprotokoll an die Slaveknoten, die es dann wiedergeben, um Master-Slave-Datenkonsistenz zu erreichen.

Sie können mit dem folgenden Befehl eine Verbindung zum MySQL-Server herstellen und die aktuellen Binärprotokolldaten anzeigen:

//Den Inhalt der Binlog-Datei anzeigen show binlog events;

//Den Inhalt der angegebenen Binärlogdatei anzeigen. Binärlog-Ereignisse in „MySQL-bin.000001“ anzeigen.

//Sehen Sie sich die Binärprotokolldatei an, die geschrieben wird. Show Master Status\G
 
//Liste der Binärprotokolldateien abrufen. Binärprotokolle anzeigen.

Wie die XA-Spezifikation definiert ist

XA ist eine von der X/Open-Organisation vorgeschlagene verteilte Transaktionsspezifikation. Die XA-Spezifikation definiert hauptsächlich die Schnittstelle zwischen dem Transaktionskoordinator (Transaction Manager) und dem Ressourcenmanager (Resource Manager).

Transaktionsmanager

Da XA-Transaktionen auf einem Zwei-Phasen-Commit-Protokoll basieren, ist ein Koordinator erforderlich, um sicherzustellen, dass alle Transaktionsteilnehmer die Vorbereitungsarbeiten abgeschlossen haben, die die erste Phase von 2PC darstellen.

Wenn der Transaktionskoordinator eine Nachricht erhält, dass alle Teilnehmer bereit sind, benachrichtigt er alle Transaktionen, dass sie festgeschrieben werden können. Dies ist die zweite Phase von 2PC.

Der Grund, warum ein Transaktionskoordinator eingeführt werden muss, besteht darin, dass in einem verteilten System zwei Maschinen theoretisch keinen konsistenten Zustand erreichen können und zur Koordination ein einzelner Punkt eingeführt werden muss.

Ressourcenmanager

Verantwortlich für die Steuerung und Verwaltung der eigentlichen Ressourcen, beispielsweise einer Datenbank oder einer JMS-Warteschlange.

Derzeit unterstützen alle gängigen Datenbanken XA. Die JMS-Spezifikation, nämlich der Java Message Service, definiert auch die Unterstützung für Transaktionen, die auf XA basieren.

XA-Transaktionsausführungsprozess

Eine XA-Transaktion ist eine Implementierung eines zweiphasigen Commits. Gemäß der 2PC-Spezifikation unterteilt XA eine Transaktion in zwei Phasen, nämlich Vorbereitung und Commit.

Vorbereitungsphase

TM sendet Vorbereitungsanweisungen an alle RMs. Nach Erhalt der Anweisungen führt RM Vorgänge wie Datenänderung und Protokollierung aus und sendet dann eine Nachricht an TM zurück, die angibt, ob die Aufgabe übermittelt werden kann oder nicht.

Wenn der Transaktionskoordinator TM eine Nachricht erhält, dass alle Teilnehmer bereit sind, benachrichtigt er alle Transaktionen über die Durchführung des Commits und tritt dann in die zweite Phase ein.

Commit-Phase

TM empfängt die Vorbereitungsergebnisse von allen RMs. Wenn ein RM zurückmeldet, dass das Ergebnis nicht übermittelt werden kann oder die Zeit abgelaufen ist, sendet das TM einen Rollback-Befehl an alle RMs.

Wenn alle RMs zurückgeben, dass die Transaktion übermittelt werden kann, wird ein Commit-Befehl an alle RMs gesendet, um einen Transaktionsvorgang abzuschließen.

Wie MySQL die XA-Spezifikation implementiert

Es gibt zwei Arten von XA-Transaktionen in MySQL: interne und externe XA. Der Unterschied besteht darin, ob die Transaktion auf einem einzelnen MySQL-Server oder zwischen mehreren externen Knoten erfolgt.

Interner XA

Wenn in der InnoDB-Speicher-Engine von MySQL Binlog aktiviert ist, verwaltet MySQL sowohl das Binlog-Protokoll als auch das Redo-Protokoll von InnoDB. Um die Konsistenz der beiden Protokolle sicherzustellen, verwendet MySQL XA-Transaktionen. Da dies auf einer einzelnen MySQL-Maschine funktioniert, wird es als internes XA bezeichnet.

Interne XA-Transaktionen sind Koordinatoren von Binlog. Wenn eine Transaktion festgeschrieben wird, müssen die Festschreibungsinformationen in das Binärprotokoll geschrieben werden. Mit anderen Worten: Der Teilnehmer von Binlog ist MySQL selbst.

Externes XA

Externes XA ist eine typische verteilte Transaktion. MySQL unterstützt SQL-Anweisungen wie XA START/END/PREPARE/Commit. Verteilte Transaktionen können mithilfe dieser Befehle abgeschlossen werden.

Weitere XA-Befehle finden Sie auch in der offiziellen MySQL-Dokumentation.

MySQL External XA wird hauptsächlich in der Datenbank-Proxy-Schicht verwendet, um verteilte Transaktionsunterstützung für MySQL-Datenbanken zu implementieren, beispielsweise in der mittleren Schicht von Open-Source-Datenbanken wie TDDL von Taobao, Cobar von Alibaba B2B usw.

Externes XA wird im Allgemeinen für verteilte Transaktionen über mehrere MySQL-Instanzen hinweg verwendet, wobei die Anwendungsschicht als Koordinator fungieren muss. Wenn wir beispielsweise Geschäftscode schreiben, entscheiden wir, ob wir im Code ein Commit oder ein Rollback durchführen und ihn im Falle eines Absturzes wiederherstellen.

Xid im Binlog

Wenn eine Transaktion festgeschrieben wird, wird dem internen XA, auf das sich das Binärprotokoll stützt, eine zusätzliche Xid-Struktur hinzugefügt. Das Binärprotokoll verfügt über mehrere Datentypen:

1. Anweisungsformat, Datensätze sind grundlegende Anweisungen, einschließlich Commit
2. Zeilenformat, Datensätze basieren auf Zeilen
3. gemischtes Format, Protokolldatensätze verwenden gemischtes Format

Unabhängig von Anweisung oder Zeilenformat fügt binlog am Ende der Transaktion ein XID_EVENT hinzu. Dieses Ereignis zeichnet die Transaktions-ID, also Xid, auf. Wenn MySQL eine Wiederherstellung nach einem Absturz durchführt, entscheidet es anhand des Status des Commits im binlog, wie die Wiederherstellung erfolgen soll.

Binlog-Synchronisierungsprozess

Schauen wir uns den Transaktionsübermittlungsprozess unter Binlog an. Der Gesamtprozess besteht darin, zuerst das Redo-Protokoll und dann das Binlog zu schreiben. Das erfolgreiche Schreiben des Binlogs wird als Zeichen für eine erfolgreiche Transaktionsübermittlung verwendet.

Wenn eine Transaktion festgeschrieben wird:

• InnoDB tritt in die Vorbereitungsphase ein und schreibt/synchronisiert Redo-Protokolle, schreibt Redo-Protokolle, schreibt die Transaktions-XID in die Redo-Protokolle und führt keine Vorgänge an Binärprotokollen aus.
• Binlog schreiben/synchronisieren, Binlog-Protokoll schreiben und auch XID in Binlog schreiben
• Rufen Sie das Commit der InnoDB-Engine auf, um die Transaktion abzuschließen und die Commit-Informationen in das Redo-Protokoll zu schreiben

Wenn der erste und zweite Schritt fehlschlagen, wird die gesamte Transaktion zurückgesetzt.

Wenn der dritte Schritt fehlschlägt, prüft MySQL nach dem Neustart, ob die XID festgeschrieben wurde. Wenn dies nicht der Fall ist, d. h. die Transaktion muss erneut ausgeführt werden, führt es einen weiteren Festschreibungsvorgang in der Speicher-Engine aus, um die Konsistenz der Redo-Log- und Binlog-Daten sicherzustellen und Datenverlust zu verhindern.

Die eigentliche Ausführung umfasst auch den Zeitpunkt, zu dem der Cache-Puffer des Betriebssystems mit dem Dateisystem synchronisiert wird. Daher unterstützt MySQL Benutzer dabei, anzupassen, wie die Protokolle im Protokollpuffer beim Commit in die Protokolldatei geleert werden. Dies wird durch den Wert der Variablen innodb_flush_log_at_trx_Commit bestimmt.

Der Inhalt des Protokollpuffers wird als Dirty Log bezeichnet. Wenn Sie interessiert sind, können Sie die Informationen überprüfen, um mehr zu erfahren.

Oben finden Sie Einzelheiten dazu, wie MySQL-Datenbanken die XA-Spezifikation implementieren. Weitere Informationen zur MySQL-Datenbank-XA-Spezifikation finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!