Bei Sitimobil verwenden wir eine MySQL-Datenbank als primären Speicher für dauerhafte Daten. Wir haben mehrere Datenbankcluster für verschiedene Dienste und Zwecke.

Die ständige Verfügbarkeit des Masters ist ein kritischer Indikator für die Funktionsfähigkeit des gesamten Systems und seiner einzelnen Teile. Die automatische Wiederherstellung des Clusters im Falle eines Masterausfalls reduziert die Reaktionszeit auf Vorfälle und die Ausfallzeit des Systems erheblich. In diesem Artikel werde ich das Schema zur Gewährleistung der hohen Verfügbarkeit (HA) eines MySQL-Clusters basierend auf MySQL Orchestrator und virtuellen IP-Adressen (VIP) erläutern.

HA-Lösung auf Basis von VIP

Zunächst gebe ich einen kurzen Überblick über unsere Datenspeicherlösung.

Wir verwenden ein klassisches Replikationsschema mit einem Master, der schreibfähig ist, und mehreren Replikaten, die nur für Lesezwecke genutzt werden. Der Cluster kann einen Zwischensmaster enthalten – einen Knoten, der gleichzeitig als Replikat und Master für andere dient. Kunden greifen über HAProxy auf die Replikate zu, was eine gleichmäßige Lastverteilung und einfache Skalierbarkeit ermöglicht. Der Einsatz von HAProxy hat historische Gründe, und wir befinden uns derzeit in der Migration zu ProxySQL.

Die Replikation erfolgt im halb-synchronen Modus basierend auf GTID. Das bedeutet, dass mindestens ein Replikat die Transaktion im Protokoll speichern muss, bevor sie als erfolgreich angesehen wird. Dieser Replikationsmodus gewährleistet einen optimalen Ausgleich zwischen Leistung und Datensicherheit im Falle eines Ausfalls des Hauptknotens. Im Wesentlichen werden alle Änderungen vom Master an die Replikate mithilfe von Row Based Replication (RBR), jedoch können einige Knoten ein gemischtes binlog-Format haben..

Der Orchestrator aktualisiert regelmäßig den Status der Cluster-Topologie, analysiert die erhaltenen Informationen und kann im Falle von Problemen den automatischen Wiederherstellungsprozess starten. Die Verantwortung für den Prozess liegt beim Entwickler, da dieser auf verschiedene Arten umgesetzt werden kann: basierend auf VIP, DNS, unter Verwendung von Dienstentdeckungsdiensten oder selbstgeschriebenen Mechanismen.

Eine der einfachen Möglichkeiten, einen Master bei einem Ausfall wiederherzustellen, besteht darin, fließende VIP-Adressen zu verwenden.

Folgendes sollten Sie über diese Lösung wissen, bevor Sie fortfahren:

• VIP ist eine IP-Adresse, die nicht an ein bestimmtes physisches Netzwerk-Interface gebunden ist. Wenn ein Knoten ausfällt oder Wartungsarbeiten erforderlich sind, können wir die VIP schnell auf eine andere Ressource umschalten, um die Ausfallzeit zu minimieren.
• Das Freigeben und Zuweisen einer virtuellen IP-Adresse sind kostengünstige und schnelle Vorgänge.
• Um mit VIP zu arbeiten, benötigen Sie Zugriff auf den Server über SSH oder die Verwendung spezieller Dienstprogramme, wie zum Beispiel keepalived.

Betrachten wir mögliche Probleme mit unserem Master und illustrieren, wie der Mechanismus der automatischen Wiederherstellung funktionieren sollte.

Die Netzwerkverbindung zum Master ist verloren gegangen oder es gibt ein Problem auf Hardware-Ebene, wodurch der Server nicht erreichbar ist.

1. Der Orchestrator aktualisiert die Cluster-Topologie, jede Replik meldet die Nichtverfügbarkeit des Masters. Der Orchestrator startet den Prozess zur Auswahl einer Replik, die als neuer Master geeignet ist, und beginnt mit der Wiederherstellung.
2. Wir versuchen, die VIP vom alten Master zu entfernen – ohne Erfolg.
3. Die Replik wechselt die Rolle zum Master. Die Topologie wird neu aufgebaut.
4. Wir fügen ein neues Netzwerkinterface mit VIP hinzu. Da das Entfernen der VIP nicht gelungen ist, starten wir im Hintergrund regelmäßig Anfragen. gratuitous ARP. Dieser Anfrage-/Antworttyp ermöglicht es, die IP- und MAC-Adresstabelle auf den angeschlossenen Switches zu aktualisieren und informiert so über den Umzug unserer VIP. Dies minimiert die Wahrscheinlichkeit eines split brain bei der Rückkehr des alten Masters.
5. Alle neuen Verbindungen werden sofort auf den neuen Master umgeleitet. Alte Verbindungen enden erfolglos, wiederholte Anfragen an die Datenbank auf Anwendungsebene erfolgen.

Der Server arbeitet im normalen Betrieb, es gab einen Ausfall auf DBMS-Ebene.

Der Algorithmus entspricht dem vorherigen Fall: Aktualisierung der Topologie und Start des Wiederherstellungsprozesses. Da der Server verfügbar ist, geben wir erfolgreich die VIP auf dem alten Master frei, übertragen sie auf den neuen und senden mehrere ARP-Anfragen. Eine mögliche Rückkehr des alten Masters sollte den wiederhergestellten Cluster und die Funktionalität der Anwendung nicht beeinträchtigen.

Weitere Probleme

Ausfälle von Repliken oder Zwischen-Mastern führen nicht zu automatischen Handlungen und erfordern manuelles Eingreifen.

Das virtuelle Netzwerk-Interface wird stets temporär hinzugefügt, das heißt, nach einem Serverneustart wird die VIP automatisch nicht neu zugewiesen. Jede Datenbankinstanz wird standardmäßig im Nur-Lese-Modus gestartet, der Orchestrator schaltet den neuen Master automatisch auf Schreibzugriff um und versucht, read only auf dem alten Master festzulegen. Diese Maßnahmen zielen darauf ab, die Wahrscheinlichkeit zu verringern. split brain.

Während des Wiederherstellungsprozesses können Probleme auftreten, die ebenfalls über die UI des Orchestrators benachrichtigt werden sollten, zusätzlich zu den Standardüberwachungsmethoden. Wir haben die REST API erweitert, um diese Möglichkeit hinzuzufügen (PR wird derzeit geprüft).

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

Auswahl eines neuen Masters

Der Orchestrator ist intelligent genug und bemüht sich, das am besten geeignete Replica auszuwählen als neuen Master gemäß den folgenden Kriterien:

• Verzögerung der Replica zum Master;
• MySQL-Version des Masters und der Replica;
• Replikationstyp (RBR, SBR oder gemischt);
• Standort in einem oder verschiedenen Rechenzentren;
• die Existenz errant GTID — Transaktionen, die auf der Replica ausgeführt wurden und auf dem Master fehlen;
• benutzerdefinierte Auswahlregeln werden ebenfalls berücksichtigt.

Nicht jede Replica ist ein idealer Kandidat für die Rolle des Masters. Beispielsweise kann eine Replica zur Datensicherung verwendet werden, oder der Server hat eine schwächere Hardware-Konfiguration. Der Orchestrator unterstützt manuelle Regeln, mit denen Sie Ihre Präferenzen für die Kandidatenauswahl von den bevorzugtesten bis zu den ignorierten anpassen können.

Reaktions- und Wiederherstellungszeit

Im Falle eines Vorfalls ist es wichtig, die Ausfallzeit des Systems zu minimieren. Daher betrachten wir die MySQL-Parameter, die die Erstellung und Aktualisierung der Cluster-Topologie durch den Orchestrator beeinflussen:

• slave_net_timeout — die Anzahl an Sekunden, in denen eine Replik darauf wartet, neue Daten oder ein Heartbeat-Signal vom Master zu empfangen, bevor die Verbindung als verloren betrachtet wird und eine Neukonfiguration erfolgt. Je geringer der Wert, desto schneller kann die Replik feststellen, dass die Verbindung zum Master unterbrochen ist. Wir setzen diesen Wert auf 5 Sekunden.
• MASTER_CONNECT_RETRY — die Anzahl an Sekunden zwischen den Versuchen zur Wiederverbindung. Bei Netzwerkproblemen ermöglicht ein niedrigerer Wert dieser Parameter, sich schnell wieder zu verbinden und einen Wiederherstellungsprozess des Clusters zu vermeiden. Der empfohlene Wert beträgt 1 Sekunde.
• MASTER_RETRY_COUNT — die maximale Anzahl an Wiederverbindungsversuchen.
• MASTER_HEARTBEAT_PERIOD — das Intervall in Sekunden, nach dem der Master ein Heartbeat-Signal sendet. Standardmäßig beträgt es die Hälfte des Wertes slave_net_timeout.

Parameter des Orchestrators:

• DelayMasterPromotionIfSQLThreadNotUpToDate — wenn es gleich ist true, wird die Rolle des Masters nicht auf die Kandidaten-Replik angewendet, bis der SQL-Thread der Replik alle nicht angewandten Transaktionen aus dem Relay Log ausgeführt hat. Wir nutzen diese Option, um in Situationen mit Verzögerungen bei allen Kandidaten-Replikationen Transaktionen nicht zu verlieren.
• InstancePollSeconds — Frequenz der Erstellung und Aktualisierung der Topologie.
• RecoveryPollSeconds — Frequenz der Topologieanalyse. Bei Feststellung eines Problems wird die Wiederherstellung der Topologie gestartet. Dies ist eine Konstante, die 1 Sekunde beträgt.

Jeder Knoten im Cluster wird einmal pro InstancePollSeconds Sekunde vom Orchestrator abgefragt. Bei Feststellung eines Problems wird der Status des Clusters zwangsweise aktualisiert, und es wird dann eine endgültige Entscheidung über die Durchführung der Wiederherstellung getroffen. Durch das Experimentieren mit verschiedenen Parametern der Datenbank und des Orchestrators konnten wir die Reaktions- und Wiederherstellungszeiten auf bis zu 30 Sekunden senken.

Teststand

Wir haben mit der Entwicklung einer lokalen Testumgebung begonnen und diese anschließend in Test- und Produktionsumgebungen implementiert. Die lokale Umgebung ist vollständig automatisiert und basiert auf Docker, was es ermöglicht, mit der Konfiguration des Orchestrators und des Netzwerks zu experimentieren, das 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 Methoden zur Emulation eines Problems: Sofortige Abschaltung des Masters mithilfe von kill -9, sanftes Beenden des Prozesses und Herunterfahren des Servers (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 innerhalb von 10 Sekunden;
• die Wiederherstellungsprozedur wird automatisch gestartet: die Netzwerkkonfiguration ändert sich, die Rolle des Masters wechselt zu einem Replikat, die Topologie wird neu aufgebaut;
• der neue Master wird für Schreibvorgänge verfügbar sein, aktive Replikate gehen während des Umbaus nicht verloren;
• Daten werden im neuen Master gespeichert 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 synthetischer und realer Belastung usw. unterschiedlich verhalten. Daher führen wir regelmäßig Übungen unter realen Bedingungen durch, um zu überprüfen, wie sich das System beim Verlust der Netzwerkkonnektivität oder bei der Degeneration einzelner Komponenten verhält. Zukünftig möchten wir eine identische Infrastruktur für beide Umgebungen aufbauen und deren Tests automatisieren.

Fazit

Die Funktionsfähigkeit des Hauptknotens des Speichersystems ist eine der zentralen Aufgaben des SRE-Teams und des Betriebs. Die Implementierung eines Orchestrators und einer HA-Lösung basierend auf VIP hat folgende Ergebnisse erzielt:

• zuverlässige Erkennung von Problemen in der Cluster-Topologie;
• automatisierte und schnelle Reaktion auf Vorfälle im Zusammenhang mit dem Master, was die Ausfallzeit des Systems reduziert.

Allerdings hat die Lösung ihre Einschränkungen und Nachteile:

• Die Skalierung der HA-Architektur über mehrere Rechenzentren erfordert ein einheitliches L2-Netzwerk zwischen ihnen;
• Bevor wir VIP auf dem neuen Master zuweisen, müssen wir es auf dem alten freigeben. Der Prozess ist sequenziell, was die Wiederherstellungszeit verlängert;
• Die Freigabe von VIP erfordert SSH-Zugriff auf den Server oder einen anderen Weg, um Remote-Prozeduren aufzurufen. Da der Server oder die DB Probleme hat, die den Wiederherstellungsprozess verursacht haben, können wir nicht sicher sein, dass die Freigabe von VIP erfolgreich ist. Das könnte zu zwei Servern mit derselben virtuellen IP-Adresse und damit zu Problemen führen. split brain.

Um dies zu vermeiden split brain, kann die Methode verwendet werden STONITH („Shoot The Other Node In The Head“), das problematische Nodes vollständig isoliert oder deaktiviert. Es gibt auch andere Methoden zur Realisierung der hohen Verfügbarkeit eines Clusters: eine Kombination aus VIP und DNS, Dienstentdeckung und Proxy-Services, synchrone Replikation sowie andere Methoden, die sowohl Vor- als auch Nachteile haben.

Ich habe über unseren Ansatz zur Schaffung eines ausfallsicheren MySQL-Clusters gesprochen. Er ist einfach umzusetzen und bietet ein akzeptables Maß an Zuverlässigkeit unter den aktuellen Bedingungen. Mit der Weiterentwicklung des gesamten Systems und insbesondere der Infrastruktur wird sich dieser Ansatz zweifellos weiterentwickeln.

Quelle: habr.com