Jedes größere Projekt begann mit ein paar Servern. Zuerst gab es einen DB-Server, später wurden Slaves hinzugefügt, um das Lesen zu skalieren. Und dann – halt! Es gibt einen Herrn, aber viele Sklaven. Wenn einer der Slaves geht, ist alles in Ordnung, aber wenn der Master geht, wird es schlimm: Ausfallzeit, die Administratoren sind damit beschäftigt, den Server hochzufahren. Was zu tun? Reservemeister. Mein Kollege Pavel hat bereits darüber geschrieben , ich werde es nicht wiederholen. Stattdessen erkläre ich Ihnen, warum Sie unbedingt Orchestrator für MySQL benötigen!
Beginnen wir mit der Hauptfrage: „Wie übertragen wir den Code auf eine neue Maschine, wenn der Master geht?“
- Mir gefällt das VIP-Schema (Virtual IP) am besten und wir werden weiter unten darüber sprechen. Dies ist die einfachste und naheliegendste Methode, weist jedoch eine offensichtliche Einschränkung auf: Der Master, den wir sichern möchten, muss sich im L2-Segment einer neuen Maschine befinden, d. h. wir können den zweiten DC vergessen. Und um ehrlich zu sein, wenn Sie der Regel folgen, dass ein großes L2 böse ist, weil L2 nur auf dem Rack ist und zwischen den Racks L3 ist, dann hat ein solches Schema noch mehr Einschränkungen.
- Sie können den 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 typische Einschränkung, d. h. es ist möglich, DC-übergreifend zu organisieren. Doch dann stellt sich die offensichtliche Frage: Wie schnell können wir eine Änderung über Puppet-Ansible an /etc/hosts übertragen?
- Die zweite Methode kann leicht modifiziert werden: Auf allen Webservern installieren wir einen Caching-DNS, über den der Code an die Masterdatenbank gelangt. Sie können für diesen Eintrag im DNS TTL 60 angeben. Es scheint, dass die Methode gut ist, wenn sie richtig implementiert wird.
- Ein Schema mit Serviceerkennung, das die Verwendung von Consul und etcd impliziert.
- Interessante Option mit . Der gesamte Datenverkehr zu MySQL muss über ProxySQL geleitet werden. ProxySQL selbst kann bestimmen, wer der aktuelle Master ist. Eine der Einsatzmöglichkeiten dieses Produktes können Sie übrigens in meinem .
Der Autor von Orchestrator, der bei Github arbeitet, hat zuerst das erste Schema mit VIP implementiert und es dann in das Schema mit Consul konvertiert.
Typisches Infrastrukturschema:
Ich werde gleich die offensichtlichen Situationen beschreiben, die berücksichtigt werden müssen:
- Die VIP-Adresse darf auf keinem der Server in der Konfiguration angegeben werden. Stellen wir uns eine Situation vor: Der Master wurde neu gestartet und während des Ladevorgangs wechselte Orchestrator in den Failover-Modus und machte einen der Slaves zum Master. dann stieg der Altmeister auf, und nun der VIP in zwei Autos. Das ist schlecht.
- Für den Orchestrator müssen Sie ein Skript schreiben, um den alten und den neuen Master zu kontaktieren. Auf dem alten müssen Sie ifdown ausführen und auf dem neuen Master ifup vip. Es wäre gut, in diesem Skript auch aufzunehmen, dass im Falle eines Failovers der Port auf dem alten Master-Switch einfach ausgeschaltet wird, um ein Splitbrain zu vermeiden.
- Nachdem Orchestrator Ihr Skript aufgerufen hat, um zuerst den VIP herunterzufahren und/oder den Port auf dem Switch herunterzufahren, und dann das VIP-Up-Skript auf dem neuen Master aufgerufen hat, vergessen Sie nicht, per ARP allen mitzuteilen, dass der neue VIP jetzt da ist.
- Alle Slaves sollten read_only=1 haben und sobald Sie einen Slave zum Master befördern, sollte er read_only=0 haben.
- Vergessen Sie nicht, dass jeder Slave, den wir hierfür ausgewählt haben, ein Master werden kann (Orchestrator verfügt über einen ganzen Präferenzmechanismus, der bestimmt, welcher Slave zuerst als Kandidat für einen neuen Master in Betracht gezogen wird, welcher als zweiter und welcher Slave unter keinen Umständen als Master ausgewählt werden sollte). Wird ein Slave zum Master, so bleibt die Last des Slaves auf ihm bestehen und die Last des Masters kommt hinzu, dies muss berücksichtigt werden.
Warum brauchen Sie Orchestrator, wenn Sie ihn nicht haben?
- Orchestrator verfügt über eine sehr benutzerfreundliche grafische Oberfläche, die die gesamte Topologie anzeigt (siehe Screenshot unten).
- Orchestrator kann verfolgen, welche Slaves in Rückstand geraten sind und wo die Replikation vollständig zusammengebrochen ist (wir haben Skripte zum Senden von SMS an Orchestrator angehängt).
- Orchestrator teilt Ihnen mit, welche Slaves einen fehlerhaften GTID-Wert aufweisen.
Orchestrator-Schnittstelle:
Was ist GTID errant?
Damit Orchestrator funktioniert, müssen zwei Hauptanforderungen erfüllt sein:
- Es ist erforderlich, dass Pseudo-GTID auf allen Maschinen im MySQL-Cluster aktiviert ist. wir haben GTID aktiviert.
- Es ist notwendig, dass überall eine Art von Binlogs vorhanden ist, eine entsprechende Anweisung ist möglich. Wir hatten eine Konfiguration, bei der der Master und die meisten Slaves über Row verfügten und zwei historisch im gemischten Modus blieben. Dies führte dazu, dass Orchestrator diese Slaves einfach nicht mit dem neuen Master verbinden wollte.
Denken Sie daran, dass das Wichtigste bei einem Produktions-Slave seine Konsistenz mit dem Master ist! Wenn Sie Global Transaction 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 Maschinen tatsächlich dieselben Datenänderungsanforderungen ausgeführt wurden. Mehr dazu erfahren Sie hier .
Der Orchestrator zeigt Ihnen also über den GTID-Fehler an, dass auf dem Slave Transaktionen vorhanden sind, die sich nicht auf dem Master befinden. Warum passiert das?
- Für den Slave ist read_only=1 nicht aktiviert, jemand hat eine Verbindung hergestellt und eine Anforderung zum Ändern der Daten ausgeführt.
- Für den Slave ist super_read_only=1 nicht aktiviert, daher hat der Administrator, nachdem er den Server verwirrt hatte, die Anfrage dort ausgeführt.
- Wenn Sie die beiden vorherigen Punkte berücksichtigt haben, gibt es noch einen weiteren Trick: In MySQL wird die Anforderung zum Leeren von Binlogs auch an das Binlog gesendet, sodass beim ersten Leeren auf dem Master und auf allen Slaves ein GTID-Fehler auftritt. Wie kann man das vermeiden? In perona-5.7.25-28 wurde eine Einstellung binlog_skip_flush_commands=1 hinzugefügt, die das Schreiben von Flush in Binlogs verbietet. Es gibt eine Website auf mysql.com .
Um das oben Genannte zusammenzufassen. Wenn Sie Orchestrator noch nicht im Failover-Modus verwenden möchten, versetzen Sie ihn in den Überwachungsmodus. Dann haben Sie immer eine Karte der Interaktionen zwischen MySQL-Maschinen vor sich und klare Informationen darüber, welche Art von Replikation auf jeder Maschine stattfindet, ob Slaves hinterherhinken und, was am wichtigsten ist, wie konsistent sie mit dem Master sind!
Die offensichtliche Frage ist: „Wie sollte Orchestrator funktionieren?“ Es muss einen neuen Master aus den aktuellen Slaves auswählen und dann alle Slaves erneut mit ihm verbinden (dafür ist die GTID da; wenn Sie den alten Mechanismus mit binlog_name und binlog_pos verwenden, ist das Umschalten eines Slaves vom aktuellen Master auf den neuen einfach unmöglich!). Bevor wir Orchestrator hatten, musste ich das alles manuell machen. Der alte Master war aufgrund eines fehlerhaften Adaptec-Controllers hängengeblieben und hatte etwa 10 Slaves. Ich musste VIP vom Master auf einen der Slaves übertragen und alle anderen Slaves erneut damit verbinden. Wie viele Konsolen musste ich öffnen, wie viele Befehle musste ich gleichzeitig eingeben... Ich musste bis 3 Uhr morgens warten, alle Slaves bis auf zwei entlasten, die erste der beiden Maschinen zum Master machen, die zweite Maschine sofort daran anschließen, dann alle anderen Slaves an den neuen Master anschließen und die Last wieder zurückgeben. Im Allgemeinen ist es schrecklich …
Wie verhält sich Orchestrator, wenn es in den Failover-Modus wechselt? Am einfachsten lässt sich dies anhand des Beispiels einer Situation veranschaulichen, in der wir eine leistungsfähigere, modernere Maschine als die, die wir jetzt haben, zu einem Meister machen wollen.
Die Abbildung zeigt die Mitte des Prozesses. Was wurde bis jetzt schon getan? Wir sagten, dass wir einen Slave zum neuen Master machen wollten, Orchestrator begann einfach damit, 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 das VIP vom alten Master, überträgt es auf den neuen, macht read_only=0 und vergisst den alten Master. Alle! Die Ausfallzeit unseres Dienstes ist die VIP-Übertragungszeit, die 2–3 Sekunden beträgt.
Das ist alles für heute, vielen Dank an alle. Der zweite Artikel über Orchestrator folgt in Kürze. In dem berühmten sowjetischen Film „Garage“ sagte eine Figur: „Ich würde nicht mit ihm auf Aufklärungsmission gehen!“ Also, Orchestrator, ich würde mit Ihnen auf Erkundungstour gehen!
Source: habr.com
