In dieser dreiteiligen Blogserie haben wir in Teil I ein Hochverfügbarkeits-Framework (HA) für MySQL-Hosting vorgestellt und in Teil II die Details der semisynchronen MySQL-Replikation besprochen. In Teil III untersuchen wir nun, wie das Framework einige der wichtigen MySQL-Fehlerszenarien handhabt und wiederhergestellt wird, um eine hohe Verfügbarkeit sicherzustellen.
MySQL-Fehlerszenarien
Szenario 1 – Master MySQL fällt aus
- Das Corosync- und Pacemaker-Framework erkennt, dass das Master-MySQL nicht mehr verfügbar ist. Pacemaker stuft die Master-Ressource herab und versucht, wenn möglich, die Wiederherstellung durch einen Neustart des MySQL-Dienstes durchzuführen.
- Zu diesem Zeitpunkt wurden aufgrund der halbsynchronen Natur der Replikation alle auf dem Master festgeschriebenen Transaktionen von mindestens einem der Slaves empfangen.
- Pacemaker wartet, bis alle empfangenen Transaktionen auf die Slaves angewendet wurden, und lässt die Slaves ihre Beförderungspunkte melden. Die Score-Berechnung erfolgt so, dass der Score „0“ ist, wenn ein Slave vollständig mit dem Master synchron ist, und ansonsten eine negative Zahl ist.
- Pacemaker wählt den Slave aus, der die Punktzahl 0 gemeldet hat, und befördert diesen Slave, der nun die Rolle des Master-MySQL übernimmt, auf dem Schreibvorgänge erlaubt sind.
- Nach der Slave-Promotion löst der Ressourcen-Agent ein DNS-Umleitungsmodul aus. Das Modul aktualisiert den Proxy-DNS-Eintrag mit der IP-Adresse des neuen Masters und erleichtert so die Umleitung aller Anwendungsschreibvorgänge an den neuen Master.
- Pacemaker richtet auch die verfügbaren Slaves ein, um mit der Replikation von diesem neuen Master zu beginnen.
Sobald ein Master-MySQL ausfällt (sei es aufgrund eines MySQL-Absturzes, eines Betriebssystemabsturzes, eines Systemneustarts usw.), erkennt unser HA-Framework dies und befördert einen geeigneten Slave zu übernehmen die Rolle des Meisters. Dadurch wird sichergestellt, dass das System weiterhin für die Anwendungen verfügbar ist.
#MySQL High Availability Framework erklärt – Teil III:FehlerszenarienClick To Tweet
Szenario 2 – Slave-MySQL fällt aus
- Das Corosync- und Pacemaker-Framework erkennt, dass das Slave-MySQL nicht mehr verfügbar ist.
- Pacemaker versucht, die Ressource wiederherzustellen, indem versucht wird, MySQL auf dem Knoten neu zu starten. Wenn es auftaucht, wird es wieder als Slave zum aktuellen Master hinzugefügt und die Replikation wird fortgesetzt.
- Wenn die Wiederherstellung fehlschlägt, meldet Pacemaker diese Ressource als ausgefallen – basierend darauf können Warnungen oder Benachrichtigungen generiert werden. Bei Bedarf übernimmt das Support-Team von ScaleGrid die Wiederherstellung dieses Knotens.
- In diesem Fall gibt es keine Auswirkungen auf die Verfügbarkeit von MySQL-Diensten.
Szenario 3 – Netzwerkpartition – Netzwerkkonnektivität bricht zwischen Master- und Slave-Knoten zusammen
Dies ist ein klassisches Problem in jedem verteilten System, wo jeder Knoten denkt, dass die anderen Knoten ausgefallen sind, während in Wirklichkeit nur die Netzwerkkommunikation zwischen den Knoten unterbrochen ist. Dieses Szenario ist allgemein als Split-Brain-Szenario bekannt und kann, wenn es nicht richtig gehandhabt wird, dazu führen, dass mehr als ein Knoten behauptet, ein Master-MySQL zu sein, was wiederum zu Dateninkonsistenzen und -beschädigungen führt.
Lassen Sie uns anhand eines Beispiels überprüfen, wie unser Framework mit Split-Brain-Szenarien im Cluster umgeht. Wir gehen davon aus, dass der Cluster aufgrund von Netzwerkproblemen in zwei Gruppen aufgeteilt wurde – Master in einer Gruppe und 2 Slaves in der anderen Gruppe, und wir bezeichnen dies als [(M), (S1,S2)].
- Corosync erkennt, dass der Master-Knoten nicht mit den Slave-Knoten kommunizieren kann und die Slave-Knoten miteinander kommunizieren können, aber nicht mit dem Master .
- Der Master-Knoten kann keine Transaktionen festschreiben, da die halbsynchrone Replikation eine Bestätigung von mindestens einem der Slaves erwartet, bevor der Master festschreiben kann. Gleichzeitig fährt Pacemaker MySQL auf dem Master-Knoten aufgrund fehlenden Quorums basierend auf der Pacemaker-Einstellung „no-quorum-policy =stop“ herunter. Quorum bedeutet hier eine Mehrheit der Knoten oder zwei von drei in einem 3-Knoten-Cluster-Setup. Da in dieser Partition des Clusters nur ein Master-Knoten läuft, wird die No-Quorum-Policy-Einstellung ausgelöst, was zum Herunterfahren des MySQL-Masters führt.
- Jetzt erkennt Pacemaker auf der Partition [(S1), (S2)], dass im Cluster kein Master verfügbar ist, und leitet einen Heraufstufungsprozess ein. Unter der Annahme, dass S1 mit dem Master auf dem neuesten Stand ist (wie durch halbsynchrone Replikation garantiert), wird es dann zum neuen Master hochgestuft.
- Anwendungsdatenverkehr wird zu diesem neuen Master-MySQL-Knoten umgeleitet und der Slave S2 beginnt mit der Replikation vom neuen Master.
Daher sehen wir, dass das MySQL HA-Framework Split-Brain-Szenarien effektiv handhabt und sowohl die Datenkonsistenz als auch die Verfügbarkeit sicherstellt, falls die Netzwerkverbindung zwischen Master- und Slave-Knoten unterbrochen wird.
P>Dies schließt unsere dreiteilige Blogserie über das MySQL High Availability (HA)-Framework mit semisynchroner Replikation und dem Corosync plus Pacemaker-Stack ab. Bei ScaleGrid bieten wir hochverfügbares Hosting für MySQL auf AWS und MySQL auf Azure an, das basierend auf den in dieser Blogserie erläuterten Konzepten implementiert wird. Bitte besuchen Sie die ScaleGrid-Konsole für eine kostenlose Testversion unserer Lösungen.
