Bei SitiMobil verwenden wir eine MySQL-Datenbank als primären Speicher für persistente 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 Master-Ausfalls verringert die Reaktionszeit auf Vorfälle und die Ausfallzeit des Systems erheblich. In diesem Artikel werde ich das Schema zur Gewährleistung einer hohen Verfügbarkeit (HA) des MySQL-Clusters basierend auf MySQL Orchestrator und virtuellen IP-Adressen (VIP) erläutern.

HA-Lösung auf Basis von VIP

Zuerst möchte ich kurz erklären, wie unser Datenspeichersystem aufgebaut ist.

Wir verwenden ein klassisches Replikationsschema mit einem schreibberechtigten Master und mehreren Replikaten, die nur für Lesezwecke verwendet werden. Der Cluster kann einen Zwischen-Master enthalten – einen Knoten, der gleichzeitig auch ein Replikat und Master für andere ist. Kunden greifen über HAProxy auf die Replikate zu, was eine gleichmäßige Lastverteilung ermöglicht und eine einfache Skalierung erleichtert. Die Verwendung von HAProxy hat historische Gründe, und wir befinden uns derzeit im Prozess 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 diese als erfolgreich anerkannt wird. Dieser Replikationsmodus bietet einen optimalen Kompromiss zwischen Leistung und Datensicherheit im Falle eines Ausfalls des Master-Knotens. Hauptsächlich werden alle Änderungen vom Master an die Replikate mittels Row Based Replication (RBR), aber einige Knoten können ein gemischtes binlog-Format.

verwenden. Der Orchestrator aktualisiert regelmäßig den Zustand der Cluster-Topologie, analysiert die erhaltenen Informationen und kann im Falle von Problemen den automatischen Wiederherstellungsprozess starten. Für den Prozess selbst ist der Entwickler verantwortlich, da er auf verschiedene Arten umgesetzt werden kann: basierend auf VIP, DNS, unter Verwendung von Diensten zur Dienstentdeckung oder benutzerdefinierten Mechanismen.

Eine der einfachen Methoden zur Wiederherstellung des Masters im Falle eines Ausfalls ist die Verwendung von schwebenden VIP-Adressen.

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

• VIP ist eine IP-Adresse, die nicht an eine bestimmte physische Netzwerkschnittstelle gebunden ist. Bei einem Ausfall des Knotens oder während geplanter Wartungsarbeiten können wir die VIP auf eine andere Ressource mit minimaler Ausfallzeit umschalten.
• Die Freigabe und Zuteilung einer virtuellen IP-Adresse sind kostengünstige und schnelle Operationen.
• Für die Arbeit mit VIP ist der Zugriff auf den Server über SSH oder die Verwendung spezieller Dienstprogramme erforderlich, zum Beispiel keepalived.

Betrachten wir die möglichen Probleme mit unserem Master und wie der Mechanismus zur automatischen Wiederherstellung funktionieren sollte.

Es gibt keine Netzwerkverbindung zum Master, oder es gibt ein Problem auf der Hardware-Ebene, und der Server ist nicht verfügbar.

1. Der Orchestrator aktualisiert die Topologie des Clusters, jede Replik meldet die Nichterreichbarkeit 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 schaltet in die Rolle des Masters um. Die Topologie wird neu strukturiert.
4. Wir fügen eine neue Netzwerkschnittstelle mit VIP hinzu. Da das Entfernen der VIP nicht erfolgreich war, starten wir im Hintergrund das regelmäßige Senden von Anfragen gratuitous ARP. Diese Art von Anfrage/Antwort ermöglicht es, die Zuordnungstabelle von IP- und MAC-Adressen auf den angeschlossenen Switches zu aktualisieren, wodurch wir über den Umzug unserer VIP informieren. Dadurch wird die Wahrscheinlichkeit eines split brain bei der Rückkehr des alten Masters minimiert.
5. Alle neuen Verbindungen werden sofort an den neuen Master umgeleitet. Alte Verbindungen schlagen fehl, es erfolgen erneute Zugriffe auf die DB auf Anwendungsebene.

Der Server arbeitet im normalen Modus, es gab einen Ausfall auf der Ebene der DBMS.

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

Andere Probleme

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

Das virtuelle Netzwerk-Interface wird immer vorübergehend hinzugefügt, das heißt, nach einem Neustart des Servers wird die VIP automatisch nicht zugewiesen. Jede DB-Instanz startet standardmäßig im Nur-Lese-Modus, der Orchestrator wechselt automatisch den neuen Master auf Schreibzugriff und versucht, zu etablieren nur lesen auf dem alten Master. Diese Maßnahmen zielen darauf ab, die Wahrscheinlichkeit zu verringern split brain.

Im Wiederherstellungsprozess können Probleme auftreten, über die auch über die Benutzeroberfläche des Orchestrators neben den Standardüberwachungsinstrumenten informiert werden sollte. Wir haben die REST API erweitert, um eine solche Möglichkeit hinzuzufügen (PR ist derzeit in Prüfung).

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

Auswahl eines neuen Masters

Der Orchestrator ist ziemlich intelligent und versucht, auszuwählen die am besten geeignete Replik als neuen Master anhand der folgenden Kriterien:

• Rückstand der Replik vom Master;
• Version von MySQL des Masters und der Replik;
• Replikationsart (RBR, SBR oder gemischt);
• Standort in einem oder verschiedenen Rechenzentren;
• die Existenz fehlerhafte GTID – Transaktionen, die auf der Replik ausgeführt wurden und auf dem Master fehlen;
• es werden auch benutzerdefinierte Auswahlregeln berücksichtigt.

Nicht jede Replik ist ein idealer Kandidat für die Rolle des Masters. Beispielsweise kann eine Replik für die 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 Auswahl des Kandidaten von den am meisten bevorzugten bis zu den ignorierten konfigurieren 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 den Aufbau und die Aktualisierung der Cluster-Topologie durch den Orchestrator beeinflussen:

• slave_net_timeout – die Anzahl der Sekunden, in denen die Replik auf das Eintreffen neuer Daten oder Heartbeat-Signale vom Master wartet, bevor die Verbindung als verloren betrachtet wird und eine Wiederverbindung erfolgt. Je kleiner 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 der Sekunden zwischen den Wiederverbindungsversuchen. Bei Netzwerkproblemen ermöglicht ein niedriger Wert dieses Parameters ein schnelles Wiederverbinden und verhindert, dass der Wiederherstellungsprozess des Clusters gestartet wird. Empfohlener Wert — 1 Sekunde.
• MASTER_RETRY_COUNT — die maximale Anzahl der Wiederverbindungsversuche.
• 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 gleich true, wird die Rolle des Masters auf dem Kandidaten-Replikat nicht angewendet, solange der SQL-Thread der Replikation nicht alle ausstehenden Transaktionen aus dem Relay Log abgearbeitet hat. Wir verwenden diese Option, um Transaktionen bei der Verzögerung aller Kandidaten-Replikate nicht zu verlieren.
• InstancePollSeconds — die Frequenz der Erstellung und Aktualisierung der Topologie.
• RecoveryPollSeconds — die Frequenz der Analyse der Topologie. Bei Erkennung eines Problems wird die Wiederherstellung der Topologie gestartet. Dies ist eine Konstante, die 1 Sekunde beträgt.

Jeder Knoten des Clusters wird vom Orchestrator einmal in InstancePollSeconds Sekunden abgefragt. Bei Erkennung eines Problems wird der Status des Clusters zwangsweise aktualisiert, und dann wird eine endgültige Entscheidung über die Durchführung der Wiederherstellung getroffen. Durch Experimentieren mit verschiedenen DB- und Orchestrator-Parametern ist es uns gelungen, die Reaktions- und Wiederherstellungszeiten auf 30 Sekunden zu reduzieren.

Teststand

Wir haben die HA-Schemata getestet, indem wir eine lokale Testumgebung entwickelt und dann in Test- und Produktionsumgebungen implementiert haben. Die lokale Testumgebung ist vollständig automatisiert auf Basis von Docker und ermöglicht es, 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 Methoden zur Emulation eines Problems: den Master sofort abzuschalten mittels kill -9, den Prozess sanft zu beenden und den Server anzuhalten (docker-compose stop), Netzwerkprobleme zu 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 Wiederherstellungsprozess wird automatisch gestartet: die Netzwerk- konfiguration ändert sich, die Rolle des Masters wechselt zur Replik, die Topologie wird neu aufgebaut;
• Der neue Master wird für die Aufnahme verfügbar sein, während die Live-Replikate im Prozess des Aufbaus nicht verloren gehen;
• Die Daten werden beginnen, in den neuen Master aufgezeichnet und repliziert zu werden;
• Die Gesamtwiederherstellungszeit wird 30 Sekunden nicht überschreiten.

Wie Sie wissen, kann sich das System in Test- und Produktionsumgebungen aufgrund unterschiedlicher Hardware- und Netzwerkkonfigurationen, Unterschiede in synthetischen und realen Lasten usw. unterschiedlich verhalten. Daher führen wir regelmäßig Übungen unter realen Bedingungen durch, um zu überprüfen, wie sich das System bei Verlust der Netzwerkverbindung oder der Degeneration einzelner Teile verhält. In Zukunft möchten wir eine vollständig identische Infrastruktur für beide Umgebungen aufbauen und deren Tests automatisieren.

Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.

Die Funktionsfähigkeit des Hauptknotens des Datenspeicher-Systems ist eine der Hauptaufgaben des SRE- und Betriebsteams. Die Implementierung des Orchestrators und der HA-Lösungen auf Basis von VIP hat die folgenden Ergebnisse gebracht:

• Zuverlässige Erkennung von Problemen mit der DB-Cluster-Topologie;
• Automatische und schnelle Reaktion auf Vorfälle, die mit dem Master verbunden sind, was die Ausfallzeit des Systems reduziert.

Das Lösung hat jedoch ihre Einschränkungen und Nachteile:

• Die Skalierung des HA-Schemas auf mehrere Rechenzentren erfordert ein einheitliches L2-Netzwerk zwischen ihnen;
• Bevor wir ein VIP auf dem neuen Master zuweisen, müssen wir es freigeben auf dem alten. Der Prozess ist sequenziell, was die Wiederherstellungszeit verlängert;
• Die Freigabe des VIP erfordert SSH-Zugriff auf den Server oder irgendeine andere Methode zur Fernaufrufung von Prozessen. Da der Server oder die DB Probleme hat, die den Wiederherstellungsprozess ausgelöst haben, können wir nicht sicher sein, dass die Freigabe des VIP erfolgreich abgeschlossen wird. Dies könnte dazu führen, dass zwei Server mit derselben virtuellen IP-Adresse existieren und zu Problemen führen. split brain.

Um dies zu vermeiden split brain, kann die Methode STONITH ('Shoot The Other Node In The Head') verwendet werden, die den problematischen Knoten vollständig isoliert oder deaktiviert. Es gibt auch andere Möglichkeiten zur Umsetzung der Hochverfügbarkeit des Clusters: eine Kombination aus VIP und DNS, Dienstentdeckung und Proxy-Dienste, synchrone Replikation und andere Methoden, die ihre eigenen Vor- und Nachteile haben.

Ich habe unseren Ansatz zur Erstellung eines ausfallsicheren MySQL-Clusters erläutert. Er ist einfach umzusetzen und bietet ein akzeptables Maß an Zuverlässigkeit unter den aktuellen Bedingungen. Mit dem Fortschritt des gesamten Systems sowie der Infrastruktur wird sich dieser Ansatz zweifellos weiterentwickeln.

Quelle: habr.com