Jedes große Projekt begann mit ein paar Servern. Zuerst gab es einen DB-Server, dann kamen die Slaves hinzu, um das Lesen zu skalieren. Und hier — Stop! Es gibt nur einen Master, aber viele Slaves; wenn einer der Slaves ausfällt, ist alles in Ordnung, aber wenn der Master ausfällt — wird es schlecht: Downtime, Admins versuchen verzweifelt, den Server wieder zum Laufen zu bringen. Was tun? Den Master reservieren. Mein Kollege Pawel hat schon darüber geschrieben, ich werde das nicht wiederholen. Stattdessen werde ich erzählen, warum Sie unbedingt einen Orchestrator für MySQL benötigen!
Fangen wir mit der Hauptfrage an: „Wie werden wir den Code auf die neue Maschine umschalten, wenn der Master ausfällt?“
- Das Schema mit VIP (Virtual IP) gefällt mir am besten, darüber werden wir gleich sprechen. Es ist das einfachste und offensichtlichste, hat jedoch eine deutliche Einschränkung: Der Master, den wir reservieren werden, muss sich im L2-Segment mit der neuen Maschine befinden, das heißt, das zweite Rechenzentrum kann vergessen werden. Und ganz ehrlich, wenn man das Prinzip beachtet, dass ein großes L2 böse ist, weil es nur auf dem Rack ist und zwischen den Racks L3, hat ein solches Schema noch mehr Einschränkungen.
- Es ist möglich, im Code den DNS-Namen zu hinterlegen und ihn über /etc/hosts aufzulösen. Tatsächlich wird es keine Auflösung geben. Der Vorteil des Schemas: Es gibt keine Einschränkung, die für die erste Methode charakteristisch ist, das heißt, man kann auch Cross-Datacenter organisieren. Aber dann stellt sich die offensichtliche Frage, wie schnell wir die Änderung über Puppet-Ansible in /etc/hosts bringen können.
- Eine zweite Methode kann leicht modifiziert werden: Auf allen Web-Servern installieren wir einen DNS-Cache, über den der Code auf die Master-Datenbank zugreift. Man kann eine TTL von 60 für diesen Eintrag im DNS festlegen. Es scheint, dass die Methode bei richtiger Implementierung gut ist.
- Das Schema mit Service Discovery, das den Einsatz von Consul und etcd impliziert.
- Eine interessante Option mit . Der gesamte Traffic zu MySQL muss durch ProxySQL geleitet werden, ProxySQL kann selbst feststellen, wer gerade der Master ist. Übrigens kann man über eine der Verwendungsmöglichkeiten dieses Produkts in meinem .
Der Autor von Orchestrator hat, während er bei Github arbeitete, zunächst das erste Schema mit VIP implementiert und dann auf das Schema mit Consul umgestellt.
Typisches Infrastruktur-Schema:
Ich werde sofort die offensichtlichen Situationen beschreiben, die berücksichtigt werden müssen:
- Die VIP-Adresse darf in keiner Konfiguration auf einem der Server festgelegt werden. Stellen wir uns vor: Der Master hat sich neu gestartet, während er hochfährt, ist Orchestrator in den Failover-Modus gegangen und hat einen der Slaves zum Master erklärt; dann erscheint der alte Master wieder, und jetzt gibt es VIP auf zwei Maschinen. Das ist schlecht.
- Für den Orchestrator muss ein Skript geschrieben werden, das den alten Master und den neuen Master anspricht. Auf dem alten muss ifdown ausgeführt werden, und auf dem neuen Master — ifup vip. Es wäre auch gut, in dieses Skript aufzunehmen, dass im Falle eines Failovers der Port am Switch des alten Masters einfach abgeschaltet wird, um jegliches Split-Brain zu vermeiden.
- Nachdem der Orchestrator Ihr Skript aufgerufen hat, um zuerst die VIP zu entfernen und/oder den Port am Switch abzuschalten, und dann auf dem neuen Master das Skript zum Aktivieren der VIP aufgerufen hat, vergessen Sie nicht mit dem Befehl arping allen mitzuteilen, dass die neue VIP jetzt hier ist.
- Auf allen Slaves muss read_only=1 eingestellt sein, und sobald Sie den Slave zum Master befördern, sollte er read_only=0 haben.
- Denken Sie daran, dass jeder Slave, den wir für diesen Zweck ausgewählt haben, ein Master werden kann (der Orchestrator hat einen gesamten Mechanismus zur Bevorzugung, welcher Slave zuerst als neuer Master in Betracht gezogen wird, welcher als zweites und welcher Slave unter keinen Umständen als Master gewählt werden sollte). Wenn ein Slave Master wird, bleibt seine Last die eines Slaves und die eines Masters wird zusätzlich hinzugefügt, das muss berücksichtigt werden.
Warum benötigen Sie unbedingt den Orchestrator, wenn Sie ihn nicht haben?
- Der Orchestrator hat eine sehr benutzerfreundliche grafische Oberfläche, die die gesamte Topologie anzeigt (siehe Screenshot unten).
- Der Orchestrator kann verfolgen, welche Slaves hinterherhinken und wo die Replikation völlig fehlgeschlagen ist (wir haben Skripte für den Orchestrator, um SMS zu senden).
- Der Orchestrator sagt Ihnen, auf welchen Slaves ein GTID-Fehler vorliegt.
Benutzeroberfläche des Orchestrators:
Was ist ein GTID-Fehler?
Es gibt zwei grundlegende Anforderungen an die Verwendung des Orchestrators:
- Es muss sichergestellt sein, dass auf allen Maschinen des MySQL-Clusters das pseudo GTID aktiviert ist, bei uns ist GTID aktiviert.
- Es muss überall ein einheitlicher Typ von Binärlogs vorhanden sein, Statement ist möglich. Wir hatten eine solche Konfiguration, bei der auf dem Master und den meisten Slaves Row war, während auf zwei historisch der Modus Mixed geblieben ist. Infolgedessen wollte der Orchestrator diese Slaves einfach nicht mit dem neuen Master verbinden.
Denken Sie daran, dass das Wichtigste an einem Production-Slave seine Konsistenz mit dem Master ist! Wenn sowohl auf dem Master als auch auf dem Slave die Global Transaction ID (GTID) aktiviert ist, kann durch die Funktion gtid_subset überprüft werden, ob tatsächlich dieselben Änderungsanfragen auf diesen Maschinen ausgeführt wurden. Weitere Informationen können Sie dazu hier lesen. .
So zeigt Ihnen der Orchestrator durch den Fehler GTID errant, dass es auf dem Slave Transaktionen gibt, die nicht auf dem Master vorhanden sind. Warum passiert das?
- Der Slave hat read_only=1 nicht aktiviert, jemand hat sich angeschlossen und eine Datenänderungsanfrage ausgeführt.
- Der Slave hat super_read_only=1 nicht aktiviert, daher hat der Administrator, verwirrt über den Server, sich angemeldet und dort eine Anfrage ausgeführt.
- Wenn Sie beide vorherigen Punkte berücksichtigt haben, gibt es noch einen weiteren Trick: In MySQL wird die Anfrage zum flush der Binlogs ebenfalls in das Binlog aufgenommen. Daher erscheint beim ersten flush auf dem Master und auf allen Slaves ein GTID errant. Wie kann man das vermeiden? In perona-5.7.25-28 wurde die Einstellung binlog_skip_flush_commands=1 eingeführt, die verhindert, dass flush in die Binlogs geschrieben wird. Auf der Website mysql.com gibt es entsprechende Informationen. .
Zusammenfassend lässt sich sagen: Wenn Sie Orchestrator momentan nicht im Failover-Modus verwenden möchten, setzen Sie ihn in den Überwachungsmodus. Dann haben Sie stets eine Übersichtskarte der Interaktion zwischen MySQL-Maschinen sowie anschauliche Informationen darüber, welche Art der Replikation auf jeder Maschine vorhanden ist, ob die Slaves hinterherhinken und, das Wichtigste, wie konsistent sie mit dem Master sind!
Eine offensichtliche Frage: 'Wie sollte Orchestrator eigentlich funktionieren?'. Er sollte einen neuen Master aus den aktuellen Slaves auswählen und dann alle Slaves mit ihm verbinden (genau dafür wird GTID benötigt; wenn das alte Mechanismus mit binlog_name und binlog_pos verwendet wird, ist der Wechsel des Slaves vom aktuellen Master zu einem neuen einfach unmöglich!). Bevor wir Orchestrator hatten, musste ich einmal alles manuell machen. Der alte Master hing wegen eines fehlerhaften Adaptec-Controllers, er hatte etwa 10 Slaves. Ich musste die VIP vom Master auf einen der Slaves übertragen und alle anderen Slaves mit ihm verbinden. Wie viele Konsolen musste ich öffnen, wie viele gleichzeitige Befehle eingeben… Ich musste bis 3 Uhr morgens warten, die Last von allen Slaves, außer zwei, nehmen, die erste Maschine aus den beiden als Master festlegen, sofort die zweite Maschine anschließen, dann alle anderen Slaves zum neuen Master verbinden und die Last zurückgeben. Kurz gesagt, schrecklich…
Wie funktioniert Orchestrator, wenn er in den Failover-Modus wechselt? Am einfachsten lässt sich das anhand einer Situation zeigen, in der wir eine leistungsfähigere, modernere Maschine als Master einrichten möchten.
Das Bild zeigt die Mitte des Prozesses. Was wurde bis zu diesem Zeitpunkt bereits gemacht? Wir haben gesagt, dass wir einen Slave zum neuen Master machen wollen, der Orchestrator hat einfach begonnen, alle anderen Slaves neu zu verbinden, während der neue Master als Transitmaschine fungiert. Bei diesem Schema treten keine Fehler auf, alle Slaves arbeiten, der Orchestrator nimmt die VIP vom alten Master, überträgt sie auf den neuen, setzt read_only=0 und vergisst den alten Master. Das ist alles! Die Ausfallzeit unseres Dienstes beträgt die Zeit für die Übertragung der VIP, das sind 2-3 Sekunden.
Das wäre alles für heute, vielen Dank. Bald erscheint der zweite Artikel über Orchestrator. In dem bekannten sowjetischen Film 'Garage' sagte ein Charakter: 'Mit ihm würde ich nicht in die Aufklärung gehen!' Nun, Orchestrator, ich würde mit dir in die Aufklärung gehen!
Quelle: habr.com
