Bei Citymobil verwenden wir eine MySQL-Datenbank als unseren wichtigsten dauerhaften Datenspeicher. Wir verfügen über mehrere Datenbankcluster für verschiedene Dienste und Zwecke.

Die ständige Verfügbarkeit des Masters ist ein entscheidender Indikator für die Leistungsfähigkeit des gesamten Systems und seiner einzelnen Teile. Die automatische Cluster-Wiederherstellung im Falle eines Master-Ausfalls reduziert die Reaktionszeit bei Vorfällen und die Ausfallzeit des Systems erheblich. In diesem Artikel werde ich mir ein Hochverfügbarkeitsdesign (HA) für einen MySQL-Cluster ansehen, das darauf basiert MySQL Orchestrator und virtuelle IP-Adressen (VIP).

HA-Lösung basierend auf VIP

Zunächst erkläre ich Ihnen kurz, was unser Datenspeichersystem ist.

Wir verwenden ein klassisches Replikationsschema mit einem schreibgeschützten 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 sind derzeit dabei, auf ProxySQL zu migrieren.

Die Replikation erfolgt im halbsynchronen Modus basierend auf GTID. Das bedeutet, dass mindestens ein Replikat eine Transaktion protokollieren 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 Row Based Replication (RBR), aber einige Knoten haben möglicherweise mixed binlog format.

Der Orchestrator aktualisiert regelmäßig den Status der Cluster-Topologie, analysiert die empfangenen Informationen und kann bei Problemen einen automatischen Wiederherstellungsvorgang starten. Für das Verfahren selbst ist der Entwickler verantwortlich, da es auf unterschiedliche Weise implementiert werden kann: basierend auf VIP, DNS, unter Verwendung von Service Discovery Services oder selbst geschriebenen Mechanismen.

Eine einfache Möglichkeit, einen Master wiederherzustellen, wenn er ausfällt, 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 keiner bestimmten physischen Netzwerkschnittstelle zugeordnet ist. Wenn ein Knoten ausfällt oder während einer geplanten Wartung, können wir die 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 die Verwendung spezieller Dienstprogramme, zum Beispiel keepalived.

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

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

1. Der Orchestrator aktualisiert die Cluster-Topologie. Jedes Replikat meldet, dass der Master nicht verfügbar ist. Der Orchestrator beginnt mit der Auswahl eines Replikats, das für die Rolle des neuen Masters geeignet ist, und beginnt mit der Wiederherstellung.
2. Wir versuchen, den VIP vom Altmaster 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, senden wir regelmäßig im Hintergrund eine Anfrage unentgeltliches ARP. Mit dieser Art von Anfrage/Antwort können Sie die Zuordnungstabelle für IP- und MAC-Adressen auf den angeschlossenen Switches aktualisieren und Sie so darüber informieren, dass unser VIP umgezogen ist. Dies minimiert die Wahrscheinlichkeit split brain bei der Rückgabe des Altmeisters.
5. Alle neuen Verbindungen werden sofort zum neuen Master umgeleitet. Alte Verbindungen schlagen fehl und es erfolgen wiederholte Aufrufe der Datenbank auf Anwendungsebene.

Der Server arbeitet im Normalmodus, 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 das VIP erfolgreich auf dem alten Master frei, übertragen es auf den neuen und senden mehrere ARP-Anfragen. Die mögliche Rückkehr des alten Masters sollte keine Auswirkungen auf den neu aufgebauten Cluster und den Betrieb der Anwendung haben.

Andere Probleme

Ausfall von Replikaten oder Zwischenmastern führt nicht zu automatischen Aktionen und erfordert manuelles Eingreifen.

Eine virtuelle Netzwerkschnittstelle wird immer temporär hinzugefügt, d. h. nach einem Server-Neustart wird die VIP nicht automatisch zugewiesen. Jede Datenbankinstanz startet standardmäßig im schreibgeschützten Modus. Der Orchestrator schaltet den neuen Master automatisch auf Schreiben um und versucht, ihn zu installieren read only auf dem 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 Diagramm der HA-Lösung ist unten dargestellt.

Einen neuen Meister wählen

Der Orchestrator ist schlau genug und versucht zu wählen die am besten geeignete Nachbildung als neuer Meister nach folgenden Kriterien:

• die Replik hinkt dem Master hinterher;
• MySQL-Version von Master und Replik;
• Replikationstyp (RBR, SBR oder gemischt);
• Standort im gleichen oder unterschiedlichen Rechenzentren;
• Präsenz errant GTID – Transaktionen, die auf dem Replikat ausgeführt wurden und sich nicht auf dem Master befinden;
• Dabei werden auch benutzerdefinierte Auswahlregeln berücksichtigt.

Nicht jedes Stichwort ist ein idealer Kandidat für einen Master. Beispielsweise kann ein Replikat zum Sichern von Daten verwendet werden oder der Server verfügt über eine schwächere Hardwarekonfiguration. Orchestrator unterstützt die Manuelle Regeln, mit denen Sie Ihre Kandidatenauswahlpräferenzen von „Am meisten bevorzugt“ bis „Ignoriert“ anpassen können.

Reaktions- und Wiederherstellungszeit

Im Falle eines Vorfalls ist es wichtig, die Ausfallzeit des Systems zu minimieren. Betrachten wir daher die MySQL-Parameter, die sich auf die Erstellung und Aktualisierung der Cluster-Topologie durch den Orchestrator auswirken:

• slave_net_timeout – die Anzahl der Sekunden, die das Replikat auf neue Daten oder ein Heartbeat-Signal vom Master wartet, bevor die Verbindung als verloren erkannt und wiederhergestellt wird. Je niedriger der Wert, desto schneller kann das Replikat feststellen, dass die Kommunikation mit dem Master unterbrochen ist. Wir setzen diesen Wert auf 5 Sekunden.
• MASTER_CONNECT_RETRY — Anzahl der Sekunden zwischen Wiederverbindungsversuchen. Bei Netzwerkproblemen ermöglicht ein niedriger Wert dieses Parameters eine schnelle Wiederherstellung der Verbindung und verhindert den Start des Cluster-Wiederherstellungsprozesses. Der empfohlene Wert beträgt 1 Sekunde.
• MASTER_RETRY_COUNT — maximale Anzahl von Wiederverbindungsversuchen.
• MASTER_HEARTBEAT_PERIOD — Intervall in Sekunden, nach dem der Master ein Heartbeat-Signal sendet. Standardmäßig ist der halbe Wert slave_net_timeout.

Orchestrator-Optionen:

• DelayMasterPromotionIfSQLThreadNotUpToDate - wenn gleich true, dann wird die Masterrolle nicht auf das Kandidatenreplikat angewendet, bis der SQL-Thread des Replikats alle nicht angewendeten Transaktionen aus dem Relay-Protokoll abgeschlossen hat. Wir verwenden diese Option, um den Verlust von Transaktionen zu vermeiden, wenn alle Replikatkandidaten ins Hintertreffen geraten.
• InstancePollSeconds — Häufigkeit des Aufbaus und der Aktualisierung der Topologie.
• RecoveryPollSeconds — Häufigkeit der Topologieanalyse. Wenn ein Problem erkannt wird, wird die Wiederherstellung der Topologie eingeleitet. Das Konstante, entspricht 1 Sekunde.

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

Prüfstand

Wir haben mit der Entwicklung eines lokalen Systems begonnen, das HA-Schema zu testen Prüfstand und weitere Implementierung in Test- und Produktionsumgebungen. Der lokale Stand basiert vollständig auf Docker und ermöglicht es Ihnen, mit der Konfiguration des Orchestrators und des Netzwerks zu experimentieren, den Cluster von 2-3 Servern auf mehrere Dutzend zu skalieren und Übungen in einer sicheren Umgebung durchzuführen.

Während der Übungen wählen wir eine der Problememulationsmethoden: Schießen Sie den Master sofort mit kill -9, beenden Sie den Prozess sanft und stoppen Sie den Server (docker-compose stop), Netzwerkprobleme simulieren mit iptables -j REJECT oder iptables -j DROP. Wir erwarten folgende Ergebnisse:

• Der Orchestrator 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 Masters wird auf das Replikat übertragen und die Topologie wird neu erstellt.
• Der neue Master wird beschreibbar, Live-Repliken gehen während des Wiederherstellungsprozesses nicht verloren.
• Die Daten werden auf den neuen Master geschrieben und repliziert.
• Die gesamte Erholungszeit beträgt nicht mehr als 30 Sekunden.

Wie Sie wissen, kann sich das 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 prüfen, wie sich das System verhält, wenn die Netzwerkkonnektivität verloren geht oder einzelne Teile beschädigt sind. Zukünftig wollen wir für beide Umgebungen eine völlig identische Infrastruktur aufbauen und deren Tests automatisieren.

Befund

Der Zustand des Hauptspeichersystemknotens ist eine der Hauptaufgaben des SRE- und Betriebsteams. Durch die Implementierung der Orchestrator- und HA-Lösung auf Basis von VIP konnten wir folgende Ergebnisse erzielen:

• zuverlässige Erkennung von Problemen mit der Topologie des Datenbankclusters;
• automatische und schnelle Reaktion auf Master-bezogene Vorfälle, wodurch Systemausfallzeiten reduziert werden.

Allerdings hat die Lösung ihre Grenzen und Nachteile:

• Die Skalierung des HA-Schemas auf mehrere Rechenzentren erfordert ein einziges L2-Netzwerk zwischen ihnen.
• Bevor wir dem neuen Master VIP zuweisen, müssen wir es auf dem alten freigeben. Der Prozess ist sequentiell, was die Wiederherstellungszeit verlängert;
• Für die Freigabe des VIP ist ein SSH-Zugriff auf den Server oder eine andere Methode zum Aufrufen von Remoteprozeduren erforderlich. Da auf dem Server oder in der Datenbank Probleme auftreten, die den Wiederherstellungsprozess verursacht haben, können wir nicht sicher sein, dass die VIP-Entfernung erfolgreich abgeschlossen wird. Dies kann dazu führen, dass zwei Server mit derselben virtuellen IP-Adresse auftreten und ein Problem auftritt split brain.

Vermeiden split brain, können Sie die Methode verwenden STONITH („Shoot The Other Node In The Head“), wodurch der Problemknoten vollständig isoliert oder deaktiviert wird. Es gibt andere Möglichkeiten, Cluster-Hochverfügbarkeit zu implementieren: eine Kombination aus VIP und DNS, Diensterkennung und Proxy-Diensten, synchrone Replikation und andere Methoden, die ihre eigenen Nachteile und Vorteile haben.

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

Source: habr.com