Orchestrator für MySQL: Warum kann ein fehlersicheres Projekt ohne es nicht erstellt werden?

Jedes größere Projekt begann mit zwei Servern. Zuerst gab es einen DB-Server, dann wurden Slaves hinzugefügt, um den Messwert zu skalieren. Und hier - hör auf! Ein Meister, aber viele Sklaven; Wenn einer der Slaves geht, ist alles in Ordnung, aber wenn der Master geht, ist es schlecht: Ausfallzeiten, Administratoren in der Seife erhöhen den Server. Was zu tun ist? Reserviere den Meister. Mein Kollege Pavel hat bereits einen Artikel darüber geschrieben , ich werde ihn nicht wiederholen. Stattdessen erkläre ich Ihnen, warum Sie definitiv einen Orchestrator für MySQL benötigen!

Beginnen wir mit der Hauptfrage: "Wie werden wir den Code auf einen neuen Computer umstellen, wenn der Assistent abreist?"

• Das Schema mit VIP (Virtual IP) gefällt mir am besten. Wir werden weiter unten darauf eingehen. Es ist das einfachste und offensichtlichste, obwohl es eine offensichtliche Einschränkung hat: Der Master, den wir reservieren werden, muss mit einer neuen Maschine im L2-Segment sein, dh Sie können den zweiten DC vergessen. Und auf eine gute Weise, wenn Sie der Regel folgen, dass großes L2 böse ist, weil L2 nur pro Rack und zwischen den Racks L3 ist und ein solches Schema noch mehr Einschränkungen aufweist.
• Sie können einen DNS-Namen im Code registrieren und über / etc / hosts auflösen. In der Tat wird es keine Lösung geben. Vorteil des Schemas: Es gibt keine Einschränkungseigenschaft für die erste Methode, dh Sie können auch Cross-DCs organisieren. Aber dann stellt sich die offensichtliche Frage, wie schnell wir mit Puppet-Ansible die Änderung an / etc / hosts liefern können.
• Sie können die zweite Methode ein wenig ändern: Auf allen Webservern setzen wir Caching-DNS ein, über das der Code in die Master-Datenbank gelangt. Sie können TTL 60 für diesen Eintrag in DNS registrieren. Es scheint, dass die Methode bei richtiger Implementierung gut ist.
• Schema mit Serviceerkennung unter Verwendung von Consul und etcd.
• Eine interessante Option mit ProxySQL . Es ist notwendig, den gesamten Datenverkehr auf MySQL über ProxySQL zu verpacken. ProxySQL kann bestimmen, wer der Master jetzt ist. Eine der Optionen für die Verwendung dieses Produkts finden Sie übrigens in meinem Artikel .

Der Autor von Orchestrator implementierte während der Arbeit an Github zuerst das erste Schema mit VIP und gestaltete es dann mit c consul neu.

Typisches Infrastrukturschema:

Ich werde sofort die offensichtlichen Situationen beschreiben, die zu berücksichtigen sind:

• VIP- . : , , Orchestrator failover ; , VIP . .
• . ifdown, — ifup vip. , failover , splitbrain.
• , Orchestrator , VIP / , VIP, arping , VIP .
• Alle Slaves sollten read_only = 1 haben, und sobald Sie den Slave zum Master befördern, sollte read_only = 0 sein.
• Vergessen Sie nicht, dass jeder Slave, den wir dafür ausgewählt haben, ein Master werden kann (Orchestrator hat einen ganzen Präferenzmechanismus, welcher Slave überhaupt als Kandidat für einen neuen Master betrachtet werden sollte, welcher als zweiter und welcher Slave unter keinen Umständen überhaupt ausgewählt werden sollte Meister). Wenn der Slave ein Master wird, bleibt die Slave-Last darauf und die Master-Last wird hinzugefügt, dies muss berücksichtigt werden.

Warum brauchen Sie Orchestrator unbedingt, wenn Sie keinen haben?

• Orchestrator verfügt über eine sehr benutzerfreundliche grafische Oberfläche, die die gesamte Topologie anzeigt (siehe Abbildung unten).
• Orchestrator kann verfolgen, welche Slaves sich dahinter befinden und wo die Replikation im Allgemeinen unterbrochen ist (wir haben Skripte zum Senden von SMS an Orchestrator).
• Orchestrator teilt Ihnen mit, bei welchen Folien ein GTID-Fehler aufgetreten ist.

Orchestrator-Schnittstelle:

Was ist ein GTID-Fehler?

Es gibt zwei Grundvoraussetzungen, damit Orchestrator funktioniert:

• Es ist erforderlich, dass die Pseudo-GTID auf allen Computern im MySQL-Cluster aktiviert ist. Wir haben die GTID aktiviert.
• Es ist notwendig, dass es überall eine Art von Binlogs gibt, die Sie angeben können. Wir hatten eine solche Konfiguration, in der Row auf dem Master und auf den meisten Slaves war, und der gemischte Modus blieb historisch auf zwei. Infolgedessen wollte Orchestrator diese Slaves einfach nicht mit dem neuen Master verbinden.

Denken Sie daran, dass das Wichtigste an einem Produktionssklaven die Übereinstimmung mit dem Master ist! Wenn Sie die globale Transaktions-ID (GTID) sowohl auf dem Master als auch auf dem Slave aktiviert haben, können Sie mit der Funktion gtid_subset herausfinden, ob auf diesen Computern tatsächlich dieselben Datenänderungsanforderungen ausgeführt werden. Lesen Sie mehr dazu hier .

Daher zeigt Orchestrator Ihnen durch einen GTID-Fehler an, dass auf dem Slave Transaktionen vorhanden sind, die nicht im Assistenten enthalten sind. Warum passiert es?

• Read_only = 1 ist auf dem Slave nicht aktiviert, jemand hat eine Verbindung hergestellt und eine Anforderung zur Datenänderung ausgeführt.
• Super_read_only = 1 ist auf dem Slave nicht aktiviert, dann ging der Administrator, nachdem er den Server vertauscht hatte, hinein und führte dort eine Anforderung aus.
• Wenn Sie beide vorherigen Absätze berücksichtigt haben, gibt es noch einen Trick: In MySQL fällt auch eine Anforderung zum Löschen von Binlogs in das Binlog. Wenn Sie also das erste Mal leeren, wird im Assistenten und auf allen Slaves ein GTID-Fehler angezeigt. Wie vermeide ich das? In perona-5.7.25-28 wurde die Einstellung binlog_skip_flush_commands = 1 angezeigt, die das Schreiben von Flush in Binlogs verbietet. Es gibt einen Fehler in mysql.com .

Ich fasse alle oben genannten Punkte zusammen. Wenn Sie Orchestrator noch nicht im Failover-Modus verwenden möchten, versetzen Sie es in den Überwachungsmodus. Dann haben Sie immer eine Karte der Interaktion von MySQL-Maschinen vor Augen und klare Informationen darüber, welche Art von Replikation auf jeder Maschine, ob die Slaves im Rückstand sind und vor allem - wie viel Konsistenz sie mit dem Master haben!

Die offensichtliche Frage lautet: "Wie sollte Orchestrator funktionieren?" Er muss einen neuen Master aus den aktuellen Slaves auswählen und dann alle Slaves wieder mit ihm verbinden (dafür ist GTID gedacht; wenn Sie den alten Mechanismus mit binlog_name und binlog_pos verwenden, ist es einfach unmöglich, den Slave vom aktuellen Master zum neuen zu wechseln!). Bevor Orchestrator zu uns kam, musste ich das alles einmal manuell machen. Der alte Master stürzte aufgrund eines fehlerhaften Adaptec-Controllers ab, er hatte ungefähr 10 Slaves. Ich musste den VIP vom Master auf einen der Slaves übertragen und alle anderen Slaves wieder damit verbinden. Wie viele Konsolen musste ich öffnen, wie viele Befehle musste ich gleichzeitig eingeben ... Ich musste bis 3 Uhr morgens warten, die Last von allen Sklaven entfernen, außer zwei, das erste Auto aus zwei Meistern machen und sofort das zweite Auto daran anschließen.Nehmen Sie daher alle anderen Slaves zum neuen Master und geben Sie die Last zurück. Im Allgemeinen ist der Horror ...

Wie funktioniert Orchestrator im Failover-Modus? Dies lässt sich am einfachsten am Beispiel einer Situation zeigen, in der wir einen Master zu einer leistungsstärkeren und moderneren Maschine machen wollen als jetzt.

Die Abbildung zeigt die Mitte des Prozesses. Was wurde bisher bereits getan? Wir sagten, dass wir eine Art Slave zu einem neuen Master machen wollen, Orchestrator hat gerade damit begonnen, alle anderen Slaves wieder damit zu verbinden, und der neue Master fungiert als Transitmaschine. Bei diesem Schema treten keine Fehler auf, alle Slaves funktionieren, Orchestrator entfernt den VIP vom alten Master, überträgt auf den neuen, macht read_only = 0 und vergisst den alten Master. Alle! Die Ausfallzeit unseres Service ist die VIP-Transferzeit, sie beträgt 2-3 Sekunden.

Das ist alles für heute, danke euch allen. Bald wird es einen zweiten Artikel über Orchestrator geben. In dem berühmten sowjetischen Film "The Garage" sagte ein Held: "Ich würde nicht mit ihm aufklären!" Also, Orchestrator, ich würde mit dir zum Scout gehen!