Orchestrator für MySQL: Warum Sie ohne ihn kein fehlertolerantes Projekt erstellen können

Jedes große Projekt begann mit ein paar Servern. Zuerst gab es einen DB-Server, dann wurden Slaves hinzugefügt, um den Messwert zu skalieren. Und dann – hör auf! Es gibt einen Herrn, aber es gibt viele Sklaven; Wenn einer der Slaves geht, ist alles in Ordnung, aber wenn der Master geht, wird es schlimm: Ausfallzeiten, Administratoren versuchen, den Server hochzufahren. Was zu tun ist? Reservieren Sie einen Master. Mein Kollege Pavel hat darüber bereits geschrieben Artikel, ich werde es nicht wiederholen. Stattdessen erzähle ich Ihnen, warum Sie unbedingt Orchestrator für MySQL benötigen!

Beginnen wir mit der Hauptfrage: „Wie werden wir den Code auf eine neue Maschine umstellen, wenn der Master geht?“

• Am besten gefällt mir das Schema mit VIP (Virtual IP), wir werden weiter unten darüber sprechen. Es ist das einfachste und offensichtlichste, obwohl es eine offensichtliche Einschränkung hat: Der Master, den wir reservieren, muss sich im L2-Segment der neuen Maschine befinden, das heißt, wir können den zweiten DC vergessen. Und auf freundliche Weise, wenn Sie der Regel folgen, dass ein großes L2 böse ist, weil L2 nur pro Rack ist und L3 zwischen den Racks liegt, und ein solches Schema noch mehr Einschränkungen mit sich bringt.
• Sie können einen DNS-Namen in den Code schreiben und ihn über /etc/hosts auflösen. Tatsächlich wird es keine Lösung geben. Der Vorteil des Schemas: Es gibt keine für die erste Methode charakteristische Einschränkung, das heißt, es ist möglich, einen Cross-DC zu organisieren. Doch dann stellt sich die offensichtliche Frage: Wie schnell können wir die Änderung über Puppet-Ansible an /etc/hosts ausliefern?
• Sie können die zweite Methode ein wenig ändern: Installieren Sie Caching-DNS auf allen Webservern, über die der Code an die Masterdatenbank gelangt. Sie können für diesen Eintrag im DNS TTL 60 festlegen. Es scheint, dass die Methode gut ist, wenn sie richtig implementiert wird.
• Ein Schema mit Diensterkennung, das die Verwendung von Consul und etcd impliziert.
• Eine interessante Option mit ProxySQL. Sie müssen den gesamten Datenverkehr über ProxySQL an MySQL weiterleiten; ProxySQL selbst kann bestimmen, wer der Master ist. Über eine der Einsatzmöglichkeiten dieses Produkts können Sie übrigens in meinem nachlesen Artikel.

Der in Github arbeitende Autor von Orchestrator implementierte zunächst das erste Schema mit VIP und wandelte es dann mit Consul in ein Schema um.

Typisches Infrastrukturlayout:

Ich beschreibe gleich die offensichtlichen Situationen, die berücksichtigt werden müssen:

• Die VIP-Adresse sollte auf keinem der Server in der Konfiguration registriert sein. Stellen wir uns eine Situation vor: Der Master wurde neu gestartet, und während er geladen wurde, wechselte Orchestrator in den Failover-Modus und machte einen der Slaves zum Master. Dann stieg der Altmeister auf, und jetzt sitzt der VIP in zwei Autos. Das ist schlecht.
• Für den Orchestrator müssen Sie ein Skript zum Aufrufen des alten Masters und des neuen Masters schreiben. Auf dem alten Master müssen Sie ifdown ausführen und auf dem neuen Master – ifup vip. Es wäre schön, in dieses Skript auch aufzunehmen, dass im Falle eines Failovers der Port am Switch des alten Masters einfach abgeschaltet wird, um ein Splitbrain zu vermeiden.
• Nachdem Orchestrator Ihr Skript aufgerufen hat, um zuerst den VIP zu entfernen und/oder den Port am Switch zu löschen, und dann das VIP-Erhöhungsskript auf dem neuen Master aufgerufen hat, vergessen Sie nicht, den Befehl arping zu verwenden, um allen mitzuteilen, dass der neue VIP jetzt vorhanden ist Hier.
• Alle Slaves sollten read_only=1 haben, und sobald Sie den Slave zum Master heraufstufen, sollte er read_only=0 haben.
• Vergessen Sie nicht, dass jeder Sklave, den wir dafür ausgewählt haben, ein Meister werden kann (Orchestrator verfügt über einen ganzen Präferenzmechanismus dafür, welcher Sklave zuerst als Kandidat für einen neuen Meister in Betracht gezogen werden soll, welcher zweitens und welcher Sklave sollte). auf keinen Fall ausgewählt werden (Master). Wird der Slave zum Master, dann bleibt die Last des Slaves auf ihm und die Last des Masters kommt hinzu, dies muss berücksichtigt werden.

Warum brauchen Sie Orchestrator, wenn Sie keinen haben?

• Orchestrator verfügt über eine sehr benutzerfreundliche grafische Oberfläche, die die gesamte Topologie anzeigt (siehe Screenshot unten).
• Orchestrator kann nachverfolgen, welche Slaves im Rückstand sind und wo die Replikation im Allgemeinen zusammengebrochen ist (wir haben Skripte zum Versenden von SMS an Orchestrator angehängt).
• Orchestrator teilt Ihnen mit, welche Slaves eine fehlerhafte GTID haben.

Orchestrator-Schnittstelle:

Was ist eine fehlerhafte GTID?

Damit Orchestrator funktioniert, gibt es zwei Hauptvoraussetzungen:

• Es ist notwendig, dass Pseudo-GTID auf allen Maschinen im MySQL-Cluster aktiviert ist; wir haben GTID aktiviert.
• Es ist notwendig, dass es überall eine Art von Binlogs gibt, Sie können eine Anweisung verwenden. Wir hatten eine Konfiguration, in der der Master und die meisten Slaves über Row verfügten und zwei historisch gesehen im gemischten Modus blieben. Aus diesem Grund wollte Orchestrator diese Slaves einfach nicht mit dem neuen Master verbinden.

Denken Sie daran, dass das Wichtigste bei einem Produktions-Slave seine Konsistenz mit dem Master ist! Wenn Sie die Global Transaction ID (GTID) sowohl auf Ihrem Master als auch auf Ihrem Slave aktiviert haben, können Sie mithilfe der Funktion gtid_subset herausfinden, ob auf diesen Maschinen tatsächlich dieselben Anforderungen für Datenänderungen ausgeführt wurden. Mehr dazu können Sie hier lesen hier.

Somit zeigt Ihnen Orchestrator anhand des GTID-Fehlers an, dass es Transaktionen auf dem Slave gibt, die nicht auf dem Master sind. Warum passiert das?

• Read_only=1 ist auf dem Slave nicht aktiviert, jemand hat eine Verbindung hergestellt und eine Anfrage zur Datenänderung abgeschlossen.
• Super_read_only=1 auf dem Slave nicht aktiviert ist, ging der Administrator, nachdem er den Server verwirrt hatte, hinein und führte die Anfrage dort aus.
• Wenn Sie beide vorherigen Punkte berücksichtigt haben, gibt es noch einen Trick: In MySQL geht eine Anfrage zum Leeren von Binlogs auch an das Binlog, sodass beim ersten Leeren eine fehlerhafte GTID auf dem Master und allen Slaves angezeigt wird. Wie kann man das vermeiden? Mit Perona-5.7.25-28 wurde die Einstellung binlog_skip_flush_commands=1 eingeführt, die das Schreiben von Flush in Binlogs verhindert. Es gibt eine etablierte Version auf der Website mysql.com ein Fehler.

Lassen Sie mich alle oben genannten Punkte zusammenfassen. Wenn Sie Orchestrator noch nicht im Failover-Modus verwenden möchten, versetzen Sie es in den Beobachtungsmodus. Dann haben Sie immer eine Karte der Interaktion von MySQL-Maschinen vor Augen und visuelle Informationen darüber, welche Art von Replikation auf jeder Maschine vorhanden ist, ob die Slaves im Rückstand sind und vor allem, wie konsistent sie mit dem Master sind!

Die offensichtliche Frage ist: „Wie soll Orchestrator funktionieren?“ Er muss einen neuen Master aus den aktuellen Slaves auswählen und dann alle Slaves erneut mit ihm verbinden (dafür wird GTID benötigt; wenn Sie den alten Mechanismus mit binlog_name und binlog_pos verwenden, dann wird ein Slave vom aktuellen Master auf einen neuen umgestellt ist einfach unmöglich!). Bevor wir Orchestrator hatten, musste ich das alles einmal manuell erledigen. Der alte Master hing wegen eines fehlerhaften Adaptec-Controllers; er hatte etwa 10 Slaves. Ich musste VIP vom Master auf einen der Slaves übertragen und alle anderen Slaves wieder damit verbinden. Wie viele Konsolen musste ich öffnen, wie viele Befehle gleichzeitig eingegeben ... Ich musste bis 3 Uhr morgens warten, alle Slaves bis auf zwei entlasten, aus zwei Mastern die erste Maschine machen und sofort die zweite Maschine anschließen Schließen Sie also alle anderen Slaves an den neuen Master an und geben Sie die Last zurück. Insgesamt schrecklich...

Wie funktioniert Orchestrator, wenn er in den Failover-Modus wechselt? Dies lässt sich am einfachsten an einem Beispiel einer Situation veranschaulichen, in der wir aus einem Master eine leistungsstärkere und modernere Maschine machen wollen, als wir sie jetzt haben.

Die Abbildung zeigt die Mitte des Prozesses. Was wurde bisher bereits getan? Wir sagten, dass wir einen Slave zum neuen Master machen wollten, und Orchestrator begann einfach alle anderen Slaves wieder damit zu verbinden, wobei der neue Master als Transitmaschine fungierte. Bei diesem Schema treten keine Fehler auf, alle Slaves funktionieren, Orchestrator entfernt die VIP vom alten Master, überträgt sie auf den neuen, setzt read_only=0 und vergisst den alten Master. Alle! Die Ausfallzeit unseres Dienstes ist die VIP-Transferzeit, die 2-3 Sekunden beträgt.

Das ist alles für heute, vielen Dank an alle. Es wird bald einen zweiten Artikel über Orchestrator geben. Im berühmten sowjetischen Film „Garage“ sagte eine Figur: „Ich würde nicht mit ihm auf Erkundungstour gehen!“ Also, Orchestrator, ich würde Sie auf Erkundungstour begleiten!

Source: habr.com