Erneutes Slaven eines abgestürzten MySQL-Master-Servers im semisynchronen Replikations-Setup

In einem MySQL 5.7-Master-Slave-Setup, das die standardmäßige halbsynchrone Replikationseinstellung für rpl_semi_sync_master_wait_point verwendet , gilt ein Absturz des Masters und Failover auf den Slave als verlustfrei. Wenn der abgestürzte Master jedoch zurückkehrt, stellen Sie möglicherweise fest, dass er Transaktionen enthält, die im aktuellen Master (der zuvor ein Slave war) nicht vorhanden sind. Dieses Verhalten mag verwirrend sein, da die semisynchrone Replikation verlustfrei sein soll, aber dies ist tatsächlich ein erwartetes Verhalten in MySQL. Warum genau das passiert, wird ausführlich im Blogbeitrag von Jean-François Gagné (JF) erklärt.

Bei einem solchen Szenario empfiehlt die MySQL-Dokumentation, dass der abgestürzte Master verworfen und nicht neu gestartet werden sollte. Die Entsorgung eines solchen Servers ist jedoch teuer und ineffizient. In diesem Blog-Beitrag erläutern wir einen Ansatz zum Erkennen und Beheben von Transaktionen auf dem abgestürzten MySQL-Master-Server in einer semisynchronen Replikationskonfiguration und wie Sie ihn wieder in Ihre Master-Slave-Konfiguration einbinden können.

Warum ist es wichtig, zusätzliche Transaktionen auf dem wiederhergestellten Master zu erkennen?

Die zusätzlichen Transaktionen auf dem wiederhergestellten Master können sich auf zwei Arten manifestieren:

1. MySQL-Replikation schlägt fehl, wenn der wiederhergestellte Master erneut versklavt wird

Normalerweise passiert dies, wenn Sie einen Primärschlüssel mit automatischer Erhöhung haben. Wenn der neue MySQL-Master eine Zeile in eine solche Tabelle einfügt, schlägt die Replikation fehl, da der Schlüssel bereits auf dem Slave existiert.

Ein weiteres Szenario ist, wenn Ihre App die Transaktion wiederholt, die während des Master-Absturzes fehlgeschlagen ist. Auf dem wiederhergestellten MySQL-Master (der jetzt ein Slave ist) würde diese Transaktion tatsächlich existieren und wiederum zu einem Replikationsfehler führen.

Normalerweise sieht der MySQL-Replikationsfehler so aus:

2. Stille Inkonsistenz in den Daten zwischen dem neuen MySQL-Master und -Slave (wiederhergestellter Master)

In Fällen, in denen die Anwendung die fehlgeschlagene Transaktion nicht wiederholt und es zukünftig keine Primärschlüsselkollisionen gibt, tritt möglicherweise kein Replikationsfehler auf. Infolgedessen kann die Dateninkonsistenz unentdeckt bleiben.

In beiden oben genannten Fällen ist entweder die Hochverfügbarkeit oder die Datenintegrität Ihres MySQL-Setups beeinträchtigt, weshalb es so wichtig ist, diesen Zustand so früh wie möglich zu erkennen.

So erkennen Sie zusätzliche Transaktionen auf dem wiederhergestellten MySQL-Master

Wir können feststellen, ob es zusätzliche Transaktionen auf dem wiederhergestellten Master gibt, indem wir die MySQL-Funktion GTID (Global Transaction Identifier) ​​verwenden:

GTID_SUBSET(set1 ,Satz2 ):Bei zwei Sätzen globaler Transaktions-IDs set1 und set2 , gibt true zurück, wenn alle GTIDs in set1 befinden sich auch in set2 . Gibt andernfalls false zurück.

Lassen Sie uns ein Beispiel verwenden, um dies zu verstehen.

• GTID-Satz auf dem wiederhergestellten Master, dessen UUID lautet:„54a63bc3-d01d-11e7-bf52-000d3af93e52 “ ist:
  • '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9700,57956099-d01d-11e7-80bc-000d3af97c09:1-810'
• Der GTID-Satz des neuen Masters, dessen UUID lautet:„57956099-d01d-11e7-80bc-000d3af97c09 ’ ist:
  • '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-000d3af97c09:1-870'

Nun, wenn wir die GTID_SUBSET-Funktion als GTID_SUBSET(GTID-Satz des wiederhergestellten Masters, GTID-Satz des neuen Masters) aufrufen , ist der Rückgabewert nur dann wahr, wenn der wiederhergestellte Master keine zusätzlichen Transaktionen enthält. Da in unserem obigen Beispiel der wiederhergestellte Master die zusätzlichen Transaktionen 9691 bis 9700 hat, ist das Ergebnis der obigen Abfrage falsch.

Wie man den wiederhergestellten MySQL-Master, der zusätzliche Transaktionen hat, erneut sklavt

Basierend auf dem obigen Schritt ist es möglich zu wissen, ob der wiederhergestellte Master zusätzliche Transaktionen hat und was diese Transaktionen mit der GTID-Funktion sind:GTID_SUBTRACT(GTID set of wiederhergestellter Master, GTID-Satz des neuen Masters).

Es ist auch möglich, diese zusätzlichen Transaktionen aus den Binärprotokollen zu extrahieren und zu speichern. Es kann für Ihr Geschäftsteam nützlich sein, diese Transaktionen später zu überprüfen, um sicherzustellen, dass wir nicht versehentlich wichtige Geschäftsinformationen verlieren, auch wenn sie nicht zugesagt wurden. Sobald dies erledigt ist, brauchen wir eine Möglichkeit, diese zusätzlichen Transaktionen loszuwerden, damit der wiederhergestellte Master ohne Probleme erneut versklavt werden kann.

Eine der einfachsten Möglichkeiten, dies zu tun, besteht darin, einen Backup-Snapshot auf dem aktuellen Master zu erstellen und die Daten auf Ihrem aktuellen Slave wiederherzustellen. Denken Sie daran, dass Sie die UUID dieses Servers wie zuvor beibehalten müssen. Nachdem Sie die Daten wiederhergestellt haben, kann der Server erneut Slave werden und die Replikation beginnt am Punkt des wiederhergestellten Snapshots. Du wirst bald wieder einen gesunden Sklaven am Laufen haben!

Die obigen Schritte sind sehr mühsam, wenn Sie sie manuell ausführen müssen, aber der vollständig verwaltete MySQL-Hosting-Service von ScaleGrid kann den gesamten Prozess für Sie automatisieren, ohne dass ein Eingreifen erforderlich ist. So funktioniert es:

Wenn Ihr aktueller Master abstürzt, automatisiert ScaleGrid den Failover-Prozess und befördert einen geeigneten Slave zum neuen Master. Der alte Master wird dann wiederhergestellt und wir erkennen automatisch, ob es zusätzliche Transaktionen darauf gibt. Wenn welche gefunden werden, wird die MySQL-Bereitstellung in einen herabgesetzten Zustand versetzt, und wir verwenden automatisierte Tools, um die zusätzlichen Transaktionen für Ihre Überprüfung zu extrahieren und zu speichern. Unser Support-Team kann dann den alten Master in einen guten Zustand zurückversetzen und ihn wieder in Ihr Master-Slave-Setup einbinden, damit Sie eine fehlerfreie Bereitstellung haben!

Möchten Sie es ausprobieren? Starten Sie eine kostenlose 30-Tage-Testversion, um alle MySQL-Datenbankverwaltungsfunktionen bei ScaleGrid zu erkunden.