So implementieren Sie verteilte Transaktionen in MySQL XA

Vorwort

Es besteht kein Zweifel, dass MySQL Einzelmaschinentransaktionen gut unterstützt. Wie implementiert MySQL also verteilte Transaktionen in einem verteilten System mit mehreren Knoten? Wenn Sie beispielsweise ein Geschäftssystem entwickeln, akzeptiert es externe Anfragen und greift dann auf mehrere interne Systeme zu, um die Anfrage auszuführen. Während der Ausführung müssen wir die Werte mehrerer Datenbanken (D1, D2, D3) gleichzeitig aktualisieren. Da das System konsistent sein muss, müssen die Werte der drei Datenbanken entweder gleichzeitig erfolgreich aktualisiert oder überhaupt nicht aktualisiert werden. Andernfalls werden einige Anweisungen des Subsystems erfolgreich ausgeführt, während andere nicht ausgeführt werden. Dies führt zu Verwirrung beim Verständnis der Ergebnisse.

Wie erreicht MySQL Konsistenz beim Aktualisieren mehrerer MySQL-Datenbanken? Das ist MySQL XA. MySQL implementiert den Betrieb mehrerer Datenbanken durch Unterstützung des Zwei-Phasen-Commit-Protokolls der XA-Spezifikation.

XA-Protokoll

Wenn wir die XA-Spezifikation erwähnen, müssen wir über das DTP-Modell (Distributed Transaction Processing) sprechen. Die XA-Spezifikation legt die Kommunikationsmethode zwischen den beiden Modulen im DTP-Modell fest: dem Transaktionsmanager und dem Ressourcenmanager. DTP ist eigentlich verteilte Transaktionsverarbeitung

Die Funktionen der einzelnen Module sind wie folgt:

• AP (Anwendungsprogramm): Anwendung, definiert Transaktionsgrenzen (definiert den Beginn und das Ende einer Transaktion) und greift auf Ressourcen innerhalb der Transaktionsgrenzen zu.
• RM (Resource Manager): verwaltet gemeinsam genutzte Ressourcen und stellt externe Zugriffsschnittstellen bereit. Damit externe Programme auf gemeinsam genutzte Ressourcen wie Datenbanken zugreifen können. Darüber hinaus verfügt RM auch über die Möglichkeit, Transaktionen rückgängig zu machen.
• TM (Transaction Manager): TM ist der Koordinator verteilter Transaktionen. TM kommuniziert mit jedem RM und ist für die Verwaltung globaler Transaktionen, die Zuweisung eindeutiger Transaktionskennungen, die Überwachung des Ausführungsfortschritts von Transaktionen sowie für die Übermittlung, das Rollback, die Fehlerbehebung usw. von Transaktionen verantwortlich.

Dies ist möglicherweise zunächst schwer zu verstehen. Zusammenfassend lässt sich sagen, dass die Architektur darin besteht, dass Anwendungen auf vom Ressourcenmanager bereitgestellte gemeinsam genutzte Ressourcen zugreifen und diese verwenden und Transaktionsvorgänge über die vom Transaktionsmanager bereitgestellte Transaktionsschnittstelle (TX-Schnittstelle) definieren. Der Transaktionsmanager und die Ressourcenverwaltung führen das Zwei-Phasen-Commit-Protokoll basierend auf der XA-Spezifikation aus.
Der XA-Spezifikationsprozess ist in der folgenden Abbildung dargestellt

• Das Anwendungsprogramm AP initiiert eine Transaktionsanfrage an den Transaktionsmanager TM
• TM ruft xa_open() auf, um eine Sitzung mit dem Ressourcenmanager herzustellen
• TM ruft xa_start() auf, um den Beginn eines Transaktionszweigs zu markieren
• AP greift auf den Ressourcenmanager RM zu und definiert Operationen, wie beispielsweise das Einfügen von Datensätzen.
• TM ruft xa_end() auf, um das Ende des Transaktionszweigs zu markieren
• TM ruft xa_prepare() auf, um RM zu benachrichtigen, dass die Übermittlung des Transaktionszweigs vorbereitet werden soll. Tatsächlich handelt es sich dabei um die Übermittlungsanforderungsphase der zweiphasigen Übermittlung.
• TM ruft xa_commit() auf, um RM zu benachrichtigen, dass der Transaktionszweig festgeschrieben werden soll. Dabei handelt es sich um die Commit-Ausführungsphase des zweiphasigen Commits.
• TM ruft xa_close auf, um die Sitzung mit RM zu verwalten.
  • Diese Schnittstellen müssen der Reihe nach ausgeführt werden; beispielsweise muss die Schnittstelle „xa_start“ vor „xa_end“ stehen. Darüber hinaus ist zu beachten, dass der Transaktionsmanager lediglich den Transaktionszweig markiert und die Transaktion nicht ausführt. Der Transaktionsvorgang wird letztendlich abgeschlossen, indem die Anwendung den Ressourcenmanager benachrichtigt. Lassen Sie uns außerdem die XA-Schnittstelle zusammenfassen
• xa_start: verantwortlich für das Starten oder Fortsetzen eines Transaktionszweigs und die Verwaltung der XID für den aufrufenden Thread
• xa_end: verantwortlich für das Abbrechen der Beziehung zwischen dem aktuellen Thread und dem Transaktionszweig
• xa_prepare: verantwortlich für die Abfrage von RM, ob es bereit ist, den Transaktionszweig festzuschreiben xa_commit: benachrichtigt RM, den Transaktionszweig festzuschreiben
• xa_rollback: RM benachrichtigen, um den Transaktionszweig zurückzusetzen
  

So implementieren Sie verteilte Transaktionen mit MySQL XA

In MySQL gibt es zwei Arten von XA-Transaktionen. Eine davon ist die interne XA-Transaktion, die hauptsächlich zur Koordination der Speicher-Engine und des Binärprotokolls verwendet wird. Die andere ist die externe Transaktion, die an externen verteilten Transaktionen teilnehmen kann (z. B. verteilte Transaktionen, die von mehreren Datenbanken implementiert werden). Hier diskutieren wir hauptsächlich externe Transaktionen.

Hinweis: Verteilte Transaktionen können in MySQL nur verwendet werden, wenn die Isolationsebene auf „Serialisierbar“ eingestellt ist.
Die XA-Syntax von MySQL lautet wie folgt

XA {START|BEGIN} xid [TEILNEHMEN|FORTSETZEN]
XA VORBEREITEN xid
XA ENDE xid
XA COMMIT xid[EINE PHASE]
XA ROLLBACK xid
XA WIEDERHERSTELLEN[XID KONVERTIEREN]

Unter ihnen ist xid die Transaktions-ID, die einen Transaktionszweig eindeutig darstellt. Jeder Transaktionszweig hat eine ID.
Bestätigen Sie zunächst, ob die XA-Funktion aktiviert ist.

Stellen Sie die Isolationsebene auf serialisierbar ein

Ausführungsergebnisse

Rufen Sie zunächst den Befehl "XA START 'xid'" auf, um die XA-Transaktion in den Status ACTIVATE zu versetzen, und führen Sie dann die mehreren SQL-Anweisungen aus, aus denen die Transaktion besteht (z. B. update
t1 setze c1 = 'a', wobei id=1), d. h., es wird die Transaktionsgrenze angegeben. Rufen Sie dann „XA END ‚xid‘“ auf, um die Transaktion in den IDLE-Zustand zu versetzen, was bedeutet, die Transaktionsgrenze zu beenden.

Als Nächstes können Sie für eine XA-Transaktion im IDLE-Status einen „XA PREPARE“-Befehl oder einen „XA COMMIT...ONE PHASE“-Befehl ausführen.
PREPARE, um die Commit-Anforderungsphase des Zwei-Phasen-Commit-Protokolls auszuführen. Durch Ausführen des Befehls „XA RECOVER“ werden alle XA-Transaktionen im Status PREPARED aufgelistet. XA
COMMIT…ONE PHASE wird zum Vorbereiten und Festschreiben von Transaktionen verwendet, das heißt, zur Konvertierung in das Ein-Phasen-Protokoll und zum direkten Festschreiben von Transaktionen.

Rufen Sie abschließend „XA COMMIT“ auf, um die Transaktion festzuschreiben (oder „XA ROLLBACK“, um die Transaktion rückgängig zu machen). Dadurch wird die Konsistenz globaler Transaktionen erreicht.

Aus dem obigen Prozess können wir erkennen, dass bei verteilten Transaktionen der MySQL-Datenbank die Rolle von MySQL tatsächlich die des RM im XA-Transaktionsprozess ist und die des TM der mit dem MySQL-Server verbundene Client ist. An einer verteilten Transaktion sind im Allgemeinen mindestens zwei RMs beteiligt. Wenn wir also sagen, dass MySQL das XA-Protokoll unterstützt, beziehen wir uns auf MySQL als RM, was bedeutet, dass MySQL die Funktionen implementiert, die RM im XA-Protokoll haben sollte.

Dies ist das Ende dieses Artikels zum Verständnis, wie MySQL XA verteilte Transaktionen implementiert. Weitere Informationen zu verteilten MySQL XA-Transaktionen finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!