In CityMobile verwenden wir die MySQL-Datenbank als Hauptspeicher für persistente Daten. Wir haben mehrere Datenbankcluster für verschiedene Dienste und Zwecke.

Die ständige Verfügbarkeit des Assistenten ist ein kritischer Indikator für den Zustand des gesamten Systems und seiner einzelnen Teile. Die automatische Clusterwiederherstellung im Falle eines Assistentenfehlers reduziert die Reaktionszeit auf Vorfälle und die Systemausfallzeit erheblich. In diesem Artikel werde ich einen MySQL HA-Cluster betrachten, der auf MySQL Orchestrator und virtuellen IP-Adressen (VIP) basiert .

VIP HA-Lösung

Zunächst werde ich kurz darauf eingehen, wie unser Datenspeichersystem aussieht.

Wir verwenden das klassische Replikationsschema mit einem Nur-Schreib-Assistenten und vielen Nur-Lese-Replikaten. Ein Cluster kann einen Zwischenmaster enthalten - einen Knoten, der sowohl ein Replikat als auch ein Master für andere ist. Clients greifen über HAProxy auf Replikate zu, was eine gleichmäßige Lastverteilung und einfache Skalierbarkeit ermöglicht. Die Verwendung von HAProxy hat historische Gründe, und jetzt sind wir dabei, auf ProxySQL zu migrieren.

Die Replikation ist halbsynchron basierend aufGTID. Dies bedeutet, dass mindestens ein Replikat die Transaktion in das Protokoll schreiben muss, bevor sie als erfolgreich angesehen wird. Dieser Replikationsmodus bietet ein optimales Gleichgewicht zwischen Leistung und Datensicherheit bei Ausfall des Hauptknotens. Grundsätzlich werden alle Änderungen mithilfe von vom Master auf Replikate übertragen Row Based Replication (RBR), einige Knoten jedoch möglicherweise mixed binlog format.

Der Orchestrator aktualisiert regelmäßig den Status der Clustertopologie, analysiert die empfangenen Informationen und kann bei Problemen den automatischen Wiederherstellungsvorgang starten. Der Entwickler ist für das Verfahren selbst verantwortlich, da es auf verschiedene Arten implementiert werden kann: basierend auf VIP, DNS, mithilfe von Service Discovery-Diensten oder eigenständigen Mechanismen.

Eine der einfachsten Möglichkeiten, einen Assistenten im Fehlerfall wiederherzustellen, ist die Verwendung von schwebenden VIP-Adressen.

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

VIP ist eine IP-Adresse, die nicht an eine bestimmte physische Netzwerkschnittstelle gebunden ist. Wenn ein Knoten ausfällt oder während der geplanten Arbeit, können wir den VIP mit minimaler Ausfallzeit auf eine andere Ressource umstellen.
Das Freigeben und Ausgeben einer virtuellen IP-Adresse ist eine kostengünstige und schnelle Operation.
Für die Arbeit mit dem VIP ist beispielsweise der Zugriff auf den Server über SSH oder die Verwendung von Spezialwerkzeugen erforderlich keepalived.

Wir werden mögliche Probleme mit unserem Master prüfen und uns vorstellen, wie der automatische Wiederherstellungsmechanismus funktionieren sollte.

Die Netzwerkverbindung zum Master ist verschwunden oder auf Hardwareebene ist ein Problem aufgetreten, und der Server ist nicht verfügbar

, . , , .
VIP — .
. .
VIP. VIP , gratuitous ARP. / IP- MAC-, VIP. split brain .
Alle neuen Verbindungen werden sofort zum neuen Master umgeleitet. Alte Verbindungen schlagen fehl, es werden wiederholt Aufrufe an die Datenbank auf Anwendungsebene getätigt.

Der Server arbeitet im normalen Modus. Auf DBMS-Ebene ist ein Fehler aufgetreten

Der Algorithmus ähnelt dem vorherigen Fall: Aktualisieren der Topologie und Starten des Wiederherstellungsprozesses. Da der Server verfügbar ist, geben wir den VIP erfolgreich auf dem alten Master frei, übertragen ihn auf den neuen und senden mehrere ARP-Anfragen. Die mögliche Rückgabe des alten Assistenten sollte sich nicht auf den neu erstellten Cluster und den Betrieb der Anwendung auswirken.

Andere Probleme

Der Ausfall von Replikaten oder Zwischenmastern führt nicht zu automatischen Aktionen und erfordert manuelle Eingriffe.

Die virtuelle Netzwerkschnittstelle wird immer vorübergehend hinzugefügt, dh nach dem Neustart wird der VIP-Server nicht automatisch zugewiesen. Jede Instanz der Datenbank wird standardmäßig im schreibgeschützten Modus gestartet. Der Orchestrator schaltet den neuen Master automatisch auf Aufzeichnung um und versucht, ihn read onlyauf dem alten Master zu installieren . 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 Benutzeroberfläche des Orchestrators gemeldet werden sollten. Wir haben die REST-API um diese Funktion erweitert ( PR wird derzeit geprüft).

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

Auswählen eines neuen Assistenten

Das Orchester ist klug genug und versucht, die am besten geeignete Nachbildung als neuer Meister nach folgenden Kriterien auszuwählen:

Verzögerung der Replik vom Master;
MySQL-Assistent und Replikatversion;
Art der Replikation (RBR, SBR oder gemischt);
Standort in einem oder mehreren Rechenzentren;
Verfügbarkeit errant GTID- Transaktionen, die auf dem Replikat ausgeführt wurden und auf dem Master fehlen;
Benutzerdefinierte Auswahlregeln werden ebenfalls berücksichtigt.

Nicht jede Replik ist ein idealer Kandidat für die Rolle des Meisters. Beispielsweise kann ein Replikat zum Sichern von Daten verwendet werden, oder der Server verfügt über eine schwächere Hardwarekonfiguration. Der Orchestrator unterstützt manuelle Regeln, nach denen Sie Ihre Einstellungen für die Auswahl eines Kandidaten anpassen können, der am meisten bevorzugt bis ignoriert wird.

Reaktions- und Wiederherstellungszeit

Im Falle eines Vorfalls ist es wichtig, die Systemausfallzeit zu minimieren. Daher berücksichtigen wir die MySQL-Parameter, die sich auf die Erstellung und Aktualisierung der Clustertopologie durch das Orchester auswirken:

slave_net_timeout- Die Anzahl der Sekunden, in denen das Replikat auf neue Daten oder ein Heartbeat-Signal vom Master wartet, bevor die Verbindung als unterbrochen erkannt und die Verbindung erneut hergestellt wird. Je niedriger der Wert, desto schneller kann das Replikat feststellen, dass die Verbindung zum Master unterbrochen ist. Wir setzen diesen Wert auf 5 Sekunden.
MASTER_CONNECT_RETRY- Die Anzahl der Sekunden zwischen den Wiederverbindungsversuchen. Bei Netzwerkproblemen können Sie mit einem niedrigen Wert dieses Parameters schnell wieder eine Verbindung herstellen und den Start des Cluster-Wiederherstellungsprozesses verhindern. Der empfohlene Wert beträgt 1 Sekunde.
MASTER_RETRY_COUNT - Die maximale Anzahl von Versuchen, die Verbindung wiederherzustellen.
MASTER_HEARTBEAT_PERIOD- das Intervall in Sekunden, nach dem der Master ein Heartbeat-Signal sendet. Der Standardwert ist der halbe Wert slave_net_timeout.

Orchestrator-Optionen:

DelayMasterPromotionIfSQLThreadNotUpToDate- Wenn gleich true, wird die Rolle des Assistenten nicht auf das Kandidatenreplikat angewendet, bis der Replikat-SQL-Stream alle nicht angewendeten Transaktionen aus dem Relay Log abgeschlossen hat. Wir verwenden diese Option, um Transaktionen nicht zu verlieren, wenn alle Kandidatenreplikate im Rückstand sind.
InstancePollSeconds - die Häufigkeit des Erstellens und Aktualisierens der Topologie.
RecoveryPollSeconds- Häufigkeit der Topologieanalyse. Wenn ein Problem erkannt wird, wird die Wiederherstellung der Topologie gestartet. Dies ist eine Konstante von 1 Sekunde.

Jeder Clusterknoten wird einmal pro InstancePollSecondsSekunde vom Orchestrator abgefragt . Wenn ein Problem erkannt wird, wird der Clusterstatus zwangsweise aktualisiert , und dann wird die endgültige Entscheidung getroffen, eine Wiederherstellung durchzuführen. Durch Experimentieren mit verschiedenen Parametern der Datenbank und des Orchesters konnten wir die Dauer der Reaktion und Wiederherstellung auf 30 Sekunden reduzieren.

Prüfstand

Wir haben begonnen, das HA-Schema zu testen , indem wir einen lokalen Prüfstand entwickelt und in einer Test- und Kampfumgebung weiter implementiert haben. Der lokale Stand ist basierend auf Docker vollautomatisch und ermöglicht es Ihnen, mit der Konfiguration des Orchesters und des Netzwerks zu experimentieren, den Cluster von 2-3 Servern auf mehrere Zehner zu skalieren und Übungen in einer sicheren Umgebung durchzuführen.

Während der Übungen wählen wir eine der Methoden zur Emulation des Problems: Schießen Sie den Assistenten sofort mit kill -9, schließen Sie den Vorgang vorsichtig ab und stoppen Sie den Server ( docker-compose stop), simulieren Sie Netzwerkprobleme mit iptables -j REJECToder iptables -j DROP. Wir erwarten diese Ergebnisse:

Das Orchester erkennt Probleme mit dem Master und aktualisiert die Topologie in nicht mehr als 10 Sekunden.
Der Wiederherstellungsvorgang wird automatisch gestartet: Die Netzwerkkonfiguration ändert sich, die Rolle des Assistenten wechselt zum Replikat, die Topologie wird neu erstellt.
Der neue Master steht für die Aufnahme zur Verfügung. Live-Replikate gehen beim Wiederherstellen nicht verloren.
Daten werden in den neuen Master geschrieben und repliziert.
Die gesamte Wiederherstellungszeit beträgt nicht mehr als 30 Sekunden.

Wie Sie wissen, kann sich ein System in Test- und Produktionsumgebungen aufgrund unterschiedlicher Hardware- und Netzwerkkonfigurationen, unterschiedlicher synthetischer und realer Last usw. unterschiedlich verhalten. Daher führen wir regelmäßig Übungen unter realen Bedingungen durch und überprüfen, wie sich das System bei Verlust der Netzwerkkonnektivität oder Verschlechterung seiner Einzelteile verhält. In Zukunft wollen wir eine völlig identische Infrastruktur für beide Umgebungen aufbauen und deren Tests automatisieren.

Ergebnisse

Die Funktionsfähigkeit des Hauptknotens des Speichersystems ist eine der Hauptaufgaben des SRE-Teams und des Betriebs. Mit der Einführung des Orchesters und der auf VIP basierenden HA-Lösungen konnten folgende Ergebnisse erzielt werden:

zuverlässige Erkennung von Problemen mit der Topologie des Datenbankclusters;
Automatische und schnelle Reaktion auf Vorfälle im Zusammenhang mit dem Master, wodurch Systemausfallzeiten reduziert werden.

Die Lösung hat jedoch ihre Vor- und Nachteile:

Für die Skalierung des HA-Schemas auf mehrere Rechenzentren ist ein einziges L2-Netzwerk erforderlich.
Bevor Sie dem neuen Meister einen VIP zuweisen, müssen wir ihn vom alten befreien. Der Prozess ist sequentiell, was die Wiederherstellungszeit verlängert.
VIP SSH- , . , , , VIP . IP- split brain.

Um dies zu vermeiden split brain, können Sie die STONITH- Methode („Den anderen Knoten in den Kopf schießen“) verwenden, mit der der Problemknoten vollständig isoliert oder getrennt wird. Es gibt andere Möglichkeiten, die Hochverfügbarkeit des Clusters zu implementieren: eine Kombination aus VIP und DNS, Diensterkennung und Proxy-Diensten, synchroner Replikation und anderen Methoden, die ihre Nachteile und Vorteile haben.

Ich sprach über unseren Ansatz zum Erstellen eines MySQL-Failoverclusters. Es ist einfach zu implementieren und bietet in der aktuellen Umgebung ein akzeptables Maß an Zuverlässigkeit. Mit der Entwicklung des gesamten Systems und insbesondere der Infrastruktur wird sich dieser Ansatz zweifellos weiterentwickeln.

Orchestrator und VIP als HA-Lösung für MySQL-Cluster