Die MySQL-Replikation ist eine sehr beliebte Methode zum Erstellen hochverfügbarer Datenbankschichten. Es ist sehr bekannt, erprobt und robust. Es ist jedoch nicht ohne Einschränkungen. Einer davon ist definitiv die Tatsache, dass es nur einen „Einstiegspunkt“ verwendet – Sie haben einen dedizierten Server in der Topologie, den Master, und es ist der einzige Knoten im Cluster, an den Sie Schreibvorgänge ausgeben können. Dies führt zu schwerwiegenden Konsequenzen – der Master ist der Single Point of Failure, und sollte er ausfallen, kann kein Schreibvorgang von der Anwendung ausgeführt werden. Es ist keine Überraschung, dass viel Arbeit in die Entwicklung von Tools gesteckt wurde, die die Auswirkungen eines Master-Verlusts verringern würden. Sicher, es gibt Diskussionen, wie man an das Thema herangeht, ob das automatisierte Failover besser ist als das manuelle oder nicht. Letztendlich ist dies eine geschäftliche Entscheidung, aber sollten Sie sich entscheiden, den Automatisierungspfad einzuschlagen, werden Sie nach den Tools suchen, die Ihnen dabei helfen, dies zu erreichen. Eines der nach wie vor sehr beliebten Tools ist MHA (Master High Availability). Obwohl es vielleicht nicht mehr aktiv gepflegt wird, befindet es sich immer noch in einem stabilen Zustand und seine enorme Popularität macht es immer noch zum Rückgrat der hochverfügbaren MySQL-Replikations-Setups. Was würde jedoch passieren, wenn das MHA selbst nicht mehr verfügbar wäre? Kann es zu einem Single Point of Failure werden? Gibt es eine Möglichkeit, dies zu verhindern? In diesem Blogpost werfen wir einen Blick auf einige der Szenarien.
Das Wichtigste zuerst:Wenn Sie MHA verwenden möchten, stellen Sie sicher, dass Sie die neueste Version aus dem Repo verwenden. Verwenden Sie keine Binärversionen, da sie nicht alle Korrekturen enthalten. Die Installation ist ziemlich einfach. MHA besteht aus zwei Teilen, Manager und Node. Node soll auf Ihren Datenbankservern bereitgestellt werden. Manager wird zusammen mit dem Knoten auf einem separaten Host bereitgestellt. Also, Datenbankserver:Knoten, Verwaltungshost:Manager und Knoten.
Es ist ziemlich einfach, MHA zu kompilieren. Gehen Sie zu GitHub und klonen Sie Repositories.
https://github.com/yoshinorim/mha4mysql-manager
https://github.com/yoshinorim/mha4mysql-node
Dann geht es um:
perl Makefile.PL
make
make installMöglicherweise müssen Sie einige Perl-Abhängigkeiten installieren, wenn Sie nicht alle erforderlichen Pakete bereits installiert haben. In unserem Fall mussten wir auf Ubuntu 16.04 Folgendes installieren:
perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
perl -MCPAN -e "install Module::Install"Sobald Sie MHA installiert haben, müssen Sie es konfigurieren. Wir werden hier nicht auf Details eingehen, es gibt viele Ressourcen im Internet, die diesen Teil abdecken. Eine Beispielkonfiguration (definitiv keine Produktionskonfiguration) könnte so aussehen:
[email protected]:~# cat /etc/app1.cnf
[server default]
user=cmon
password=pass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
[server1]
hostname=node1
candidate_master=1
[server2]
hostname=node2
candidate_master=1
[server3]
hostname=node3
no_master=1Der nächste Schritt wird sein, zu sehen, ob alles funktioniert und wie MHA die Replikation sieht:
[email protected]:~# masterha_check_repl --conf=/etc/app1.cnf
Tue Apr 9 08:17:04 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 08:17:04 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations. Redundant argument in sprintf at /usr/local/share/perl/5.22.1/MHA/NodeUtil.pm line 195.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.
Tue Apr 9 08:17:05 2019 - [info] Got exit code 1 (Not master dead).Nun, es ist abgestürzt. Dies liegt daran, dass MHA versucht, die MySQL-Version zu parsen und keine Bindestriche darin erwartet. Glücklicherweise ist die Lösung leicht zu finden:https://github.com/yoshinorim/mha4mysql-manager/issues/116.
Jetzt haben wir MHA für die Arbeit bereit.
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:00:00 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:00:00 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:00:01 2019 - [info] GTID failover mode = 1
Tue Apr 9 13:00:01 2019 - [info] Dead Servers:
Tue Apr 9 13:00:01 2019 - [info] Alive Servers:
Tue Apr 9 13:00:01 2019 - [info] node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306)
Tue Apr 9 13:00:01 2019 - [info] Alive Slaves:
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Not candidate for the new Master (no_master is set)
Tue Apr 9 13:00:01 2019 - [info] Current Alive Master: node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Checking slave configurations..
Tue Apr 9 13:00:01 2019 - [info] Checking replication filtering settings..
Tue Apr 9 13:00:01 2019 - [info] binlog_do_db= , binlog_ignore_db=
Tue Apr 9 13:00:01 2019 - [info] Replication filtering check ok.
Tue Apr 9 13:00:01 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Tue Apr 9 13:00:01 2019 - [info] Checking SSH publickey authentication settings on the current master..
Tue Apr 9 13:00:02 2019 - [info] HealthCheck: SSH to node1 is reachable.
Tue Apr 9 13:00:02 2019 - [info]
node1(10.0.0.141:3306) (current master)
+--node2(10.0.0.142:3306)
+--node3(10.0.0.143:3306)
Tue Apr 9 13:00:02 2019 - [warning] master_ip_failover_script is not defined.
Tue Apr 9 13:00:02 2019 - [warning] shutdown_script is not defined.
Tue Apr 9 13:00:02 2019 - [info] Set master ping interval 3 seconds.
Tue Apr 9 13:00:02 2019 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Tue Apr 9 13:00:02 2019 - [info] Starting ping health check on node1(10.0.0.141:3306)..
Tue Apr 9 13:00:02 2019 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..Wie Sie sehen können, überwacht MHA unsere Replikationstopologie und prüft, ob der Master-Knoten verfügbar ist oder nicht. Betrachten wir ein paar Szenarien.
Szenario 1 – MHA abgestürzt
Nehmen wir an, MHA ist nicht verfügbar. Wie wirkt sich das auf die Umwelt aus? Da MHA dafür verantwortlich ist, den Zustand des Masters zu überwachen und Failover auszulösen, wird dies natürlich nicht passieren, wenn MHA ausgefallen ist. Master-Absturz wird nicht erkannt, Failover findet nicht statt. Das Problem ist, dass Sie nicht wirklich mehrere MHA-Instanzen gleichzeitig ausführen können. Technisch gesehen können Sie dies tun, obwohl sich MHA über die Sperrdatei beschweren wird:
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:05:38 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:05:38 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:05:38 2019 - [warning] /var/log/masterha/app1/app1.master_status.health already exists. You might have killed manager with SIGKILL(-9), may run two or more monitoring process for the same application, or use the same working directory. Check for details, and consider setting --workdir separately.Es wird jedoch gestartet und versucht, die Umgebung zu überwachen. Das Problem ist, wenn beide anfangen, Aktionen auf dem Cluster auszuführen. Der schlimmste Fall wäre, wenn sie sich entscheiden, verschiedene Slaves als Master-Kandidaten zu verwenden, und das Failover gleichzeitig ausgeführt wird (MHA verwendet eine Sperrdatei, die verhindert, dass nachfolgende Failover stattfinden, aber wenn alles gleichzeitig passiert, und es geschah in unserem Tests reicht diese Sicherheitsmaßnahme nicht aus).
Leider gibt es keine integrierte Möglichkeit, MHA hochverfügbar auszuführen. Die einfachste Lösung besteht darin, ein Skript zu schreiben, das testet, ob MHA läuft, und wenn nicht, startet es. Ein solches Skript müsste von Cron ausgeführt oder in Form eines Daemons geschrieben werden, wenn 1 Minute Granularität von Cron nicht ausreicht.
Szenario 2 – MHA-Manager-Knoten hat die Netzwerkverbindung zum Master verloren
Seien wir ehrlich, das ist eine wirklich schlimme Situation. Sobald MHA keine Verbindung zum Master herstellen kann, versucht es, ein Failover durchzuführen. Die einzige Ausnahme ist, wenn secondary_check_script definiert ist und verifiziert wurde, dass der Master am Leben ist. Es liegt am Benutzer, genau zu definieren, welche Aktionen MHA ausführen soll, um den Status des Masters zu überprüfen – alles hängt von der Umgebung und dem genauen Setup ab. Ein weiteres sehr wichtiges zu definierendes Skript ist master_ip_failover_script – dieses wird bei einem Failover ausgeführt und sollte unter anderem verwendet werden, um sicherzustellen, dass der alte Master nicht angezeigt wird. Wenn Sie zufällig Zugriff auf zusätzliche Möglichkeiten haben, Old Master zu erreichen und zu stoppen, ist das wirklich großartig. Das können Fernverwaltungstools wie Integrated Lights-out sein, es kann der Zugriff auf verwaltbare Steckdosen sein (wo Sie den Server einfach ausschalten können), es kann der Zugriff auf die CLI des Cloud-Anbieters sein, die es ermöglicht, die virtuelle Instanz zu stoppen . Es ist von größter Wichtigkeit, den alten Master zu stoppen - sonst kann es passieren, dass Sie nach dem Wegfall des Netzwerkproblems zwei beschreibbare Knoten im System haben, was eine perfekte Lösung für das gespaltene Gehirn ist, ein Zustand, in dem Daten, die zwischen zwei Teilen desselben Clusters divergierten.
Wie Sie sehen können, kann MHA das MySQL-Failover ziemlich gut handhaben. Es erfordert definitiv eine sorgfältige Konfiguration und Sie müssen externe Skripte schreiben, die verwendet werden, um den alten Meister zu töten und sicherzustellen, dass die Gehirnspaltung nicht auftritt. Trotzdem empfehlen wir, fortschrittlichere Failover-Management-Tools wie Orchestrator oder ClusterControl zu verwenden, die eine erweiterte Analyse des Zustands der Replikationstopologie durchführen können (z. B. durch Verwendung von Slaves oder Proxys, um die Verfügbarkeit des Masters zu bewerten) und welche sind und wird auch in Zukunft beibehalten. Wenn Sie wissen möchten, wie ClusterControl ein Failover durchführt, möchten wir Sie einladen, diesen Blogbeitrag zum Failover-Prozess in ClusterControl zu lesen. Sie können auch erfahren, wie ClusterControl mit ProxySQL interagiert und ein reibungsloses, transparentes Failover für Ihre Anwendung ermöglicht. Sie können ClusterControl jederzeit testen, indem Sie es kostenlos herunterladen.
