Bei Citymobil verwenden wir eine MySQL-Datenbank als primären Speicher für persistente Daten. Wir verfügen über mehrere Datenbankcluster für unterschiedliche Dienste und Zwecke.

Die ständige Verfügbarkeit des Masters ist ein entscheidender Indikator für die Funktionsfähigkeit des gesamten Systems und seiner Einzelteile. Durch die automatische Clusterwiederherstellung im Falle eines Masterausfalls werden die Reaktionszeit bei Vorfällen und die Systemausfallzeit erheblich verkürzt. In diesem Artikel bespreche ich ein Hochverfügbarkeitsschema (HA) für einen MySQL-Cluster basierend auf MySQL-Orchestrator und virtuelle IP-Adressen (VIP).

HA-Lösung basierend auf VIP

Lassen Sie mich Ihnen zunächst kurz erklären, was unser Datenspeichersystem ist.

Wir verwenden ein klassisches Replikationsschema mit einem beschreibbaren Master und mehreren schreibgeschützten Replikaten. Ein Cluster kann einen Zwischenmaster enthalten – einen Knoten, der sowohl eine Replik als auch ein Master für andere ist. Clients greifen über HAProxy auf Replikate zu, was eine gleichmäßige Lastverteilung und einfache Skalierung ermöglicht. Die Verwendung von HAProxy hat historische Gründe und wir befinden uns derzeit im Migrationsprozess zu ProxySQL.

Die Replikation erfolgt in einem halbsynchronen Modus basierend auf GTID. Dies bedeutet, dass mindestens eine Replik eine Transaktion in das Protokoll schreiben muss, bevor sie als erfolgreich gilt. Dieser Replikationsmodus bietet ein optimales Gleichgewicht zwischen Leistung und Datensicherheit im Falle eines Masterknotenausfalls. Grundsätzlich werden alle Änderungen vom Master auf die Replikate übertragen mit Row Based Replication (RBR), aber einige Knoten haben möglicherweise mixed binlog format.

Der Orchestrator aktualisiert regelmäßig den Status der Clustertopologie, analysiert die empfangenen Informationen und kann bei auftretenden Problemen ein automatisches Wiederherstellungsverfahren starten. Für das Verfahren selbst ist der Entwickler verantwortlich, da es auf unterschiedliche Weise implementiert werden kann: basierend auf VIP, DNS, mithilfe von Service Discovery-Diensten oder benutzerdefinierten Mechanismen.

Eine der einfachen Möglichkeiten, den Master im Falle eines Ausfalls wiederherzustellen, ist die Verwendung von Floating-VIP-Adressen.

Was Sie über diese Lösung wissen müssen, bevor Sie fortfahren:

• Eine VIP ist eine IP-Adresse, die nicht an eine bestimmte physische Netzwerkschnittstelle gebunden ist. Im Falle eines Knotenausfalls oder während einer geplanten Wartung können wir den VIP mit minimaler Ausfallzeit auf eine andere Ressource umstellen.
• Die Freigabe und Vergabe einer virtuellen IP-Adresse ist ein kostengünstiger und schneller Vorgang.
• Um mit VIP zu arbeiten, benötigen Sie Zugriff auf den Server über SSH oder verwenden Sie spezielle Dienstprogramme, zum Beispiel keepalived.

Schauen wir uns mögliche Probleme mit unserem Master an und stellen wir uns vor, wie der automatische Wiederherstellungsmechanismus funktionieren sollte.

Die Netzwerkverbindung zum Master ist verloren gegangen oder es ist ein Problem auf Hardwareebene aufgetreten und der Server ist nicht verfügbar

1. Der Orchestrator aktualisiert die Clustertopologie, jede Replik meldet die Nichtverfügbarkeit des Masters. Der Orchestrator startet den Prozess zur Auswahl einer für die Rolle des neuen Masters geeigneten Replik und beginnt mit der Wiederherstellung.
2. Wir versuchen, VIP vom alten Master zu entfernen – ohne Erfolg.
3. Das Replikat wechselt in die Rolle des Masters. Die Topologie wird neu aufgebaut.
4. Hinzufügen einer neuen Netzwerkschnittstelle mit VIP. Da es nicht möglich war, den VIP zu entfernen, starten wir einen regelmäßigen Anfrageversand im Hintergrund unentgeltliches ARP. Mit dieser Art von Anfrage/Antwort können wir die IP- und MAC-Adresszuordnungstabelle auf den verbundenen Switches aktualisieren und sie so über die Verschiebung unseres VIPs informieren. Dies minimiert die Wahrscheinlichkeit split brain bei der Rückgabe des alten Meisters.
5. Alle neuen Verbindungen werden sofort zum neuen Master umgeleitet. Alte Verbindungen schlagen fehl und auf Anwendungsebene werden wiederholte Anfragen an die Datenbank gestellt.

Der Server funktioniert normal, es gab einen Fehler auf DBMS-Ebene

Der Algorithmus ähnelt dem vorherigen Fall: Aktualisieren der Topologie und Starten des Wiederherstellungsprozesses. Da der Server verfügbar ist, geben wir den VIP auf dem alten Master erfolgreich frei, verschieben ihn auf den neuen und senden einige ARP-Anfragen. Eine mögliche Rückkehr des alten Masters sollte den neu aufgebauten Cluster- und Anwendungsbetrieb nicht beeinträchtigen.

Andere Probleme

Ausfall von Replikaten oder Zwischenmastern führt nicht auf automatische Aktionen und erfordert manuelle Eingriffe.

Das Hinzufügen der virtuellen Netzwerkschnittstelle erfolgt immer temporär, d. h. die VIP wird nach dem Serverneustart nicht automatisch zugewiesen. Jede DB-Instance startet standardmäßig im Nur-Lese-Modus, der Orchestrator schaltet den neuen Master automatisch auf Schreiben um und versucht, read only auf den alten Meister. Diese Maßnahmen zielen darauf ab, die Wahrscheinlichkeit zu verringern, split brain.

Während des Wiederherstellungsprozesses können Probleme auftreten, die zusätzlich zu den Standardüberwachungstools auch über die Orchestrator-Benutzeroberfläche gemeldet werden sollten. Wir haben die REST-API um diese Funktion erweitert (PR (derzeit in Prüfung).

Das allgemeine Schema der HA-Lösung wird unten dargestellt.

Einen neuen Meister wählen

Der Orchestrator ist klug genug und versucht zu wählen die am besten geeignete Replik als neuer Master nach folgenden Kriterien:

• Verzögerung der Replik vom Master;
• MySQL-Version von Master und Replikat;
• Replikationstyp (RBR, SBR oder gemischt);
• Standort in einem oder mehreren Rechenzentren;
• Präsenz errant GTID — Transaktionen, die auf der Replik ausgeführt wurden und auf dem Master fehlen;
• Dabei werden auch Benutzerauswahlregeln berücksichtigt.

Nicht jede Replik ist ein idealer Kandidat für die Rolle des Meisters. Beispielsweise kann eine Replik zur Datensicherung verwendet werden oder der Server verfügt über eine schwächere Hardwarekonfiguration. Orchestrator unterstützt die manuelle Regeln, mit denen Sie Ihre Präferenzen bei der Kandidatenauswahl von den am meisten bevorzugten bis zu den ignorierten anpassen können.

Reaktions- und Wiederherstellungszeit

Im Falle eines Vorfalls ist es wichtig, die Systemausfallzeit zu minimieren. Sehen wir uns daher die MySQL-Parameter an, die sich darauf auswirken, wie der Orchestrator die Clustertopologie erstellt und aktualisiert:

• slave_net_timeout – die Anzahl der Sekunden, die eine Replik auf neue Daten oder ein Heartbeat-Signal vom Master wartet, bevor die Verbindung als verloren gilt und eine erneute Verbindung hergestellt wird. Je niedriger der Wert, desto schneller kann die Replik erkennen, dass die Verbindung zum Master unterbrochen wurde. Wir setzen diesen Wert auf 5 Sekunden.
• MASTER_CONNECT_RETRY – die Anzahl der Sekunden zwischen den erneuten Verbindungsversuchen. Bei Netzwerkproblemen ermöglicht Ihnen ein niedriger Wert für diesen Parameter eine schnelle Wiederherstellung der Verbindung und verhindert, dass der Cluster-Wiederherstellungsprozess gestartet wird. Der empfohlene Wert ist 1 Sekunde.
• MASTER_RETRY_COUNT – maximale Anzahl der Wiederverbindungsversuche.
• MASTER_HEARTBEAT_PERIOD – das Intervall in Sekunden, nach dem der Master ein Heartbeat-Signal sendet. Standardmäßig ist der halbe Wert slave_net_timeout.

Orchestrator-Parameter:

• DelayMasterPromotionIfSQLThreadNotUpToDate - wenn gleich true, dann wird die Masterrolle erst dann auf das Kandidatenreplikat angewendet, wenn der SQL-Thread des Replikats alle nicht angewendeten Transaktionen aus dem Relay-Protokoll ausgeführt hat. Wir verwenden diese Option, um den Verlust von Transaktionen zu vermeiden, wenn alle Kandidatenreplikate zurückliegen.
• InstancePollSeconds — Häufigkeit der Topologieerstellung und -aktualisierung.
• RecoveryPollSeconds — Häufigkeit der Topologieanalyse. Wenn ein Problem erkannt wird, wird die Topologiewiederherstellung eingeleitet. Das Konstante, gleich 1 Sekunde.

Jeder Clusterknoten wird vom Orchestrator einmal pro InstancePollSeconds Sekunden. Wenn ein Problem erkannt wird, wird der Clusterstatus erzwungen Aktualisiert, und dann wird eine endgültige Entscheidung zur Durchführung der Wiederherstellung getroffen. Durch Experimentieren mit verschiedenen Datenbank- und Orchestratorparametern konnten wir die Reaktions- und Wiederherstellungszeit auf 30 Sekunden reduzieren.

Prüfstand

Wir begannen mit dem Testen des HA-Schemas, indem wir ein lokales Prüfstand und weitere Implementierung in Test- und Produktionsumgebungen. Der lokale Stand ist vollständig automatisiert und basiert auf Docker. Sie können mit dem Orchestrator und der Netzwerkkonfiguration experimentieren, den Cluster von 2–3 Servern auf mehrere Dutzend skalieren und Übungen in einer sicheren Umgebung durchführen.

Während des Trainings wählen wir eine der Methoden, um das Problem zu emulieren: Erschießen Sie den Meister sofort mit kill -9, beenden Sie den Prozess sanft und stoppen Sie den Server (docker-compose stop), simulieren Sie Netzwerkprobleme mit iptables -j REJECT oder iptables -j DROP. Wir erwarten folgende Ergebnisse:

• Der Orchestrator erkennt Probleme mit dem Master und aktualisiert die Topologie in höchstens 10 Sekunden.
• der Wiederherstellungsvorgang wird automatisch gestartet: Die Netzwerkkonfiguration wird geändert, die Masterrolle wird auf die Replik übertragen, die Topologie wird neu erstellt;
• Das neue Master wird für die Aufnahme verfügbar, Live-Replikate gehen während des Wiederherstellungsprozesses nicht verloren.
• Die Daten werden auf den neuen Master geschrieben und repliziert.
• die gesamte Wiederherstellungszeit beträgt nicht mehr als 30 Sekunden.

Wie Sie wissen, kann sich das System in Test- und Produktionsumgebungen aufgrund unterschiedlicher Hardware- und Netzwerkkonfigurationen, Unterschiede in der synthetischen und realen Belastung usw. unterschiedlich verhalten. Daher führen wir regelmäßig Übungen unter realen Bedingungen durch und prüfen, wie sich das System verhält, wenn die Netzwerkkonnektivität verloren geht oder die Leistung einzelner Teile beeinträchtigt wird. In Zukunft möchten wir für beide Umgebungen eine völlig identische Infrastruktur aufbauen und deren Tests automatisieren.

Befund

Die Integrität des Hauptknotens des Datenspeichersystems ist eine der Hauptaufgaben des SRE- und Betriebsteams. Durch die Implementierung der Orchestrator- und HA-Lösung auf Basis von VIP konnten wir die folgenden Ergebnisse erzielen:

• zuverlässige Erkennung von Problemen mit der DB-Cluster-Topologie;
• Automatische und schnelle Reaktion auf Vorfälle mit dem Master, wodurch Systemausfallzeiten reduziert werden.

Die Lösung hat jedoch ihre Grenzen und Nachteile:

• die Skalierung des HA-Schemas auf mehrere Rechenzentren erfordert ein einzelnes L2-Netzwerk zwischen ihnen;
• Bevor wir einem neuen Master einen VIP zuweisen können, müssen wir ihn auf dem alten freigeben. Der Prozess ist sequentiell, was die Erholungszeit verlängert.
• Für die Freigabe von VIP ist SSH-Zugriff auf den Server oder eine andere Möglichkeit zum Aufrufen von Remoteprozeduren erforderlich. Da auf dem Server oder in der Datenbank Probleme vorliegen, die den Wiederherstellungsprozess verursacht haben, können wir nicht sicher sein, dass die VIP-Entfernung erfolgreich sein wird. Und dies kann dazu führen, dass zwei Server mit der gleichen virtuellen IP-Adresse erscheinen und das Problem split brain.

Vermeiden split brainkönnen Sie die Methode verwenden STONITH („Schießen Sie dem anderen Knoten in den Kopf“), wodurch der problematische Knoten vollständig isoliert oder deaktiviert wird. Es gibt andere Möglichkeiten, die Hochverfügbarkeit eines Clusters zu implementieren: eine Kombination aus VIP und DNS, Service Discovery und Proxy-Diensten, synchroner Replikation und anderen Methoden, die ihre eigenen Nachteile und Vorteile haben.

Ich habe über unseren Ansatz zum Aufbau eines Failover-MySQL-Clusters gesprochen. Es ist einfach zu implementieren und bietet unter den aktuellen Bedingungen ein akzeptables Maß an Zuverlässigkeit. Da sich das System als Ganzes und insbesondere die Infrastruktur weiterentwickeln, wird sich dieser Ansatz zweifellos weiterentwickeln.

Source: habr.com