Für alle, die mit Vitess nicht vertraut sind, es ist ein MySQL-basiertes Datenbanksystem, das ein einfach zu skalierendes, geteiltes, relationales Datenbankverwaltungssystem liefern soll. Wir gehen nicht näher auf das Design ein, aber kurz gesagt besteht Vitess aus Proxy-Knoten, die die Anfragen weiterleiten, Gateways, die die Datenbankknoten verwalten, und schließlich aus MySQL-Datenbankknoten selbst, die die Daten speichern sollen. Wenn wir über MySQL sprechen, könnte man denken, ob es tatsächlich eine Option gibt, externe Tools wie zum Beispiel ClusterControl zu verwenden, um diese zugrunde liegenden Datenbanken zu verwalten. Kurze Antwort ist „ja“. Eine längere Antwort wird dieser Blogbeitrag sein.
MySQL in Vitess
Zunächst möchten wir ein wenig darüber sprechen, wie Vitess MySQL verwendet. Die High-Level-Architektur wird auf der Vitess-Dokumentationsseite beschrieben. Kurz gesagt, wir haben VTGate, das als Proxy fungiert, wir haben einen Topologiedienst, der ein Metadatenspeicher ist, der auf Zookeeper, Consul oder Etcd basiert, wo sich alle Informationen über die Knoten im System befinden, und schließlich haben wir VTTablets, die handeln als Mittelsmann zwischen VTGate und MySQL-Instanz. MySQL-Instanzen können eigenständig sein oder mit standardmäßiger asynchroner (oder halbsynchroner) Replikation konfiguriert werden. MySQL wird zum Speichern von Daten verwendet. Daten können in Shards aufgeteilt werden, in diesem Fall enthält eine MySQL-Instanz eine Teilmenge der Daten.
Das alles funktioniert wunderbar. Vitess kann bestimmen, welcher Knoten der Master ist, welche Knoten Slaves sind, und Anfragen entsprechend weiterleiten. Es gibt jedoch mehrere Probleme. Nicht alle grundlegenden Funktionen werden von Vitess bereitgestellt. Topologieerkennung und Abfragerouting, ja. Sicherungen – ja, Vitess kann auch so konfiguriert werden, dass es Sicherungskopien der Daten erstellt und es den Benutzern ermöglicht, die gesicherten Daten wiederherzustellen. Leider gibt es keine interne Unterstützung für automatisiertes Failover. Es gibt keine geeignete Trending-Benutzeroberfläche, die Benutzern helfen würde, den Status der Datenbanken und ihre Arbeitslast zu verstehen. Glücklicherweise können wir, da wir über Standard-MySQL sprechen, problemlos externe Lösungen verwenden, um dies zu erreichen. Beispielsweise kann Vitess für Failover in Orchestrator integriert werden. Werfen wir einen Blick darauf, wie ClusterControl in Verbindung mit Vitess verwendet werden kann, um Verwaltung, Überwachung und Failover bereitzustellen.
Bereitstellen eines neuen Datenbank-Clusters mit ClusterControl
Lassen Sie uns zuerst einen neuen Cluster bereitstellen. Wie bei ClusterControl üblich, müssen Sie Hardware bereitstellen und sicherstellen, dass ClusterControl über SSH auf diese Knoten zugreifen kann.
Zuerst müssen wir die SSH-Konnektivität definieren.
Als Nächstes wählen wir den Anbieter und die Version aus. Laut Dokumentation unterstützt Vitess MySQL und Percona Server in den Versionen 5.7 und 8.0 (obwohl es die Methode caching_sha2_password nicht unterstützt, sodass Sie beim Erstellen von Benutzern vorsichtig sein müssen). Es unterstützt auch MariaDB bis 10.3.
Schließlich definieren wir die Topologie. Nachdem Sie auf „Bereitstellen“ geklickt haben, führt ClusterControl die Clusterbereitstellung durch.
Sobald es fertig ist, sollten Sie den Cluster sehen und können verwalten Sie es mit ClusterControl. Wenn die automatische Wiederherstellung für Cluster und Knoten aktiviert ist, führt ClusterControl bei Bedarf automatische Failover durch.
Sie profitieren auch von der agentenbasierten Überwachung im Bereich „Dashboard“. der ClusterControl-Benutzeroberfläche.
Cluster in Vitess importieren
Als nächsten Schritt sollten wir Vitess einsetzen. Was wir hier beschreiben, ist keineswegs ein produktionstaugliches Setup, daher werden wir einige Abstriche machen und die Vitess-Suite einfach auf einem einzelnen Knoten bereitstellen, indem wir dem Tutorial aus der Vitess-Dokumentation folgen. Um die Handhabung zu vereinfachen, verwenden wir den Leitfaden zur lokalen Installation, der alle Dienste zusammen mit Beispieldatenbanken auf einem einzelnen Knoten bereitstellt. Machen Sie es groß genug, um sie aufzunehmen. Für Testzwecke sollte ein Knoten mit ein paar CPU-Kernen und 4 GB Speicher ausreichen.
Nehmen wir an, dass alles gut gelaufen ist und Sie eine lokale Vitess-Bereitstellung auf dem Knoten ausgeführt haben. Der nächste Schritt besteht darin, unseren von ClusterControl bereitgestellten Cluster in Vitess zu importieren. Dafür müssen wir zwei weitere VTTablets ausführen. Zuerst werden wir Verzeichnisse für diese VTTablets erstellen:
[email protected]:~$ cd /home/vagrant/my-vitess-example/
[email protected]:~/my-vitess-example$ source env.sh
[email protected]:~/my-vitess-example$ mkdir $VTDATAROOT/vt_0000000401
[email protected]:~/my-vitess-example$ mkdir $VTDATAROOT/vt_0000000402Dann werden wir in der Datenbank einen Benutzer erstellen, der für Vitess verwendet wird, um sich mit der Datenbank zu verbinden und sie zu verwalten.
mysql> CREATE USER [email protected]'%' IDENTIFIED BY 'pass';
Query OK, 0 rows affected (0.01 sec)
mysql> GRANT ALL ON *.* TO [email protected]'%' WITH GRANT OPTION;
Query OK, 0 rows affected (0.01 sec)Wenn wir möchten, möchten wir vielleicht auch mehr Benutzer erstellen. Vitess ermöglicht es uns, ein paar Benutzern mit unterschiedlichen Zugriffsrechten zu übergeben:Anwendungsbenutzer, DBA-Benutzer, Replikationsbenutzer, voll privilegierte Benutzer und ein paar mehr.
Als Letztes müssen wir super_read_only auf allen MySQL-Servern deaktivieren Knoten, da Vitess versucht, Metadaten auf dem Replikat zu erstellen, was zu einem fehlgeschlagenen Versuch führt, den vttablet-Dienst zu starten.
Sobald dies erledigt ist, sollten wir VTTablets starten. In beiden Fällen müssen wir sicherstellen, dass die Ports eindeutig sind und dass wir die richtigen Anmeldeinformationen für den Zugriff auf die Datenbankinstanz übergeben:
vttablet $TOPOLOGY_FLAGS -logtostderr -log_queries_to_file $VTDATAROOT/tmp/vttablet_0000000401_querylog.txt -tablet-path "zone1-0000000401" -init_keyspace clustercontrol -init_shard 0 -init_tablet_type replica -port 15401 -grpc_port 16401 -service_map 'grpc-queryservice,grpc-tabletmanager,grpc-updatestream' -pid_file $VTDATAROOT/vt_0000000401/vttablet.pid -vtctld_addr http://localhost:15000/ -db_host 10.0.0.181 -db_port 3306 -db_app_user vtuser -db_app_password pass -db_dba_user vtuser -db_dba_password pass -db_repl_user vtuser -db_repl_password pass -db_filtered_user vtuser -db_filtered_password pass -db_allprivs_user vtuser -db_allprivs_password pass -init_db_name_override clustercontrol -init_populate_metadata &
vttablet $TOPOLOGY_FLAGS -logtostderr -log_queries_to_file $VTDATAROOT/tmp/vttablet_0000000402_querylog.txt -tablet-path "zone1-0000000402" -init_keyspace clustercontrol -init_shard 0 -init_tablet_type replica -port 15402 -grpc_port 16402 -service_map 'grpc-queryservice,grpc-tabletmanager,grpc-updatestream' -pid_file $VTDATAROOT/vt_0000000402/vttablet.pid -vtctld_addr http://localhost:15000/ -db_host 10.0.0.182 -db_port 3306 -db_app_user vtuser -db_app_password pass -db_dba_user vtuser -db_dba_password pass -db_repl_user vtuser -db_repl_password pass -db_filtered_user vtuser -db_filtered_password pass -db_allprivs_user vtuser -db_allprivs_password pass -init_db_name_override clustercontrol -init_populate_metadata &Sobald es fertig ist, können wir prüfen, wie Vitess die neuen VTTablets sieht:
[email protected]:~/my-vitess-example$ mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 10
Server version: 5.7.9-vitess-10.0.2 Version: 10.0.2 (Git revision fc78470 branch 'HEAD') built on Thu May 27 08:45:22 UTC 2021 by [email protected] using go1.15.12 linux/amd64
Copyright (c) 2000, 2021, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> SHOW vitess_tablets;
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| Cell | Keyspace | Shard | TabletType | State | Alias | Hostname | MasterTermStartTime |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| zone1 | clustercontrol | 0 | REPLICA | SERVING | zone1-0000000401 | vagrant.vm | |
| zone1 | clustercontrol | 0 | REPLICA | SERVING | zone1-0000000402 | vagrant.vm | |
| zone1 | commerce | 0 | MASTER | SERVING | zone1-0000000100 | vagrant.vm | 2021-07-08T13:12:21Z |
| zone1 | commerce | 0 | REPLICA | SERVING | zone1-0000000101 | vagrant.vm | |
| zone1 | commerce | 0 | RDONLY | SERVING | zone1-0000000102 | vagrant.vm | |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
5 rows in set (0.00 sec)Knoten sind vorhanden, aber beide werden von Vitess als Replikate gemeldet. Wir können jetzt Vitess veranlassen, die Topologie für unseren echten Master zu prüfen (Knoten, den wir mit der ID 401 importiert haben)
[email protected]:~/my-vitess-example$ vtctlclient TabletExternallyReparented zone1-401Jetzt sieht alles richtig aus:
mysql> SHOW vitess_tablets;
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| Cell | Keyspace | Shard | TabletType | State | Alias | Hostname | MasterTermStartTime |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| zone1 | clustercontrol | 0 | MASTER | SERVING | zone1-0000000401 | vagrant.vm | 2021-07-08T13:27:34Z |
| zone1 | clustercontrol | 0 | REPLICA | SERVING | zone1-0000000402 | vagrant.vm | |
| zone1 | commerce | 0 | MASTER | SERVING | zone1-0000000100 | vagrant.vm | 2021-07-08T13:12:21Z |
| zone1 | commerce | 0 | REPLICA | SERVING | zone1-0000000101 | vagrant.vm | |
| zone1 | commerce | 0 | RDONLY | SERVING | zone1-0000000102 | vagrant.vm | |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
5 rows in set (0.00 sec)Integration von ClusterControl automatisiertem Failover in Vitess
Als Letztes möchten wir uns die automatisierte Failover-Behandlung mit ClusterControl ansehen und sehen, wie Sie sie mit Vitess integrieren können. Es wird dem, was wir gerade gesehen haben, ziemlich ähnlich sein. Das Hauptproblem besteht darin, dass das Failover nichts in Vitess ändert. Die Lösung ist das, was wir zuvor verwendet haben, der Befehl TabletExternallyReparented. Die einzige Herausforderung besteht darin, es auszulösen, wenn das Failover stattfindet. Glücklicherweise enthält ClusterControl Hooks, mit denen wir uns in den Failover-Prozess einklinken können. Wir werden sie verwenden, um den vtctlclient auszuführen. Es muss jedoch zuerst auf der ClusterControl-Instanz installiert werden. Der einfachste Weg, dies zu erreichen, besteht darin, die Binärdatei von der Vitess-Instanz nach ClusterControl zu kopieren.
Als Erstes erstellen wir das Verzeichnis auf dem ClusterControl-Knoten:
mkdir -r /usr/local/vitess/binDann kopieren Sie einfach die Datei:
scp /usr/local/vitess/bin/vtctlclient [email protected]:/usr/local/vitess/bin/Als nächsten Schritt müssen wir ein Skript erstellen, das den Befehl zur Neuzuordnung von Shards ausführt. Wir werden replication_post_failover_script und replication_post_switchover_script verwenden. Cmon führt das Skript mit mehreren Argumenten aus. Uns interessiert der dritte von ihnen, er enthält den Hostnamen des Master-Kandidaten – der Knoten, der als neuer Master ausgewählt wurde.
Das Beispielskript könnte etwa so aussehen.
#!/bin/bash
if [[ $3 == 10.0.0.181 ]] ; then tablet="zone1-401" ; fi
if [[ $3 == 10.0.0.182 ]] ; then tablet="zone1-402" ; fi
vitess="10.0.0.50"
/usr/local/vitess/bin/vtctlclient -server ${vitess}:15999 TabletExternallyReparented ${tablet}Bitte denken Sie daran, dass dies nur ein absolutes Minimum ist, das funktioniert. Sie sollten ein detaillierteres Skript implementieren, das möglicherweise zusätzliche Plausibilitätsprüfungen durchführt. Anstatt die Hostnamen und Tablet-Namen fest zu codieren, können Sie ClusterControl tatsächlich abfragen, um die Liste der Knoten im Cluster zu erhalten, dann möchten Sie sie vielleicht mit dem Inhalt des Topology Service vergleichen, um zu sehen, welcher Tablet-Alias verwendet werden sollte.
Sobald wir mit dem Skript fertig sind, sollten wir es so konfigurieren, dass es von ClusterControl ausgeführt wird:
Wir können dies testen, indem wir das Replikat manuell heraufstufen. Der Anfangszustand, wie von Vitess gesehen, war:
mysql> SHOW vitess_tablets;
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| Cell | Keyspace | Shard | TabletType | State | Alias | Hostname | MasterTermStartTime |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| zone1 | clustercontrol | 0 | MASTER | SERVING | zone1-0000000401 | vagrant.vm | 2021-07-08T13:27:34Z |
| zone1 | clustercontrol | 0 | REPLICA | SERVING | zone1-0000000402 | vagrant.vm | |
| zone1 | commerce | 0 | MASTER | SERVING | zone1-0000000100 | vagrant.vm | 2021-07-08T13:12:21Z |
| zone1 | commerce | 0 | REPLICA | SERVING | zone1-0000000101 | vagrant.vm | |
| zone1 | commerce | 0 | RDONLY | SERVING | zone1-0000000102 | vagrant.vm | |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
5 rows in set (0.00 sec)Wir interessieren uns für den Schlüsselraum „clustercontrol“. 401 (10.0.0.181) war der Master und 402 (10.0.0.182) war die Replik.
Wir können 10.0.0.182 zu einem neuen Master hochstufen. Der Job startet und wir können sehen, dass unser Skript ausgeführt wurde:
Endlich ist der Auftrag abgeschlossen:
Im ClusterControl lief alles gut. Werfen wir einen Blick auf Vitess:
mysql> SHOW vitess_tablets;
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| Cell | Keyspace | Shard | TabletType | State | Alias | Hostname | MasterTermStartTime |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| zone1 | clustercontrol | 0 | MASTER | SERVING | zone1-0000000402 | vagrant.vm | 2021-07-09T13:38:00Z |
| zone1 | clustercontrol | 0 | REPLICA | SERVING | zone1-0000000401 | vagrant.vm | |
| zone1 | commerce | 0 | MASTER | SERVING | zone1-0000000100 | vagrant.vm | 2021-07-08T13:12:21Z |
| zone1 | commerce | 0 | REPLICA | SERVING | zone1-0000000101 | vagrant.vm | |
| zone1 | commerce | 0 | RDONLY | SERVING | zone1-0000000102 | vagrant.vm | |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
5 rows in set (0.00 sec)Wie Sie sehen, ist auch hier alles in Ordnung. 402 ist der neue Master und 401 ist als Replica markiert.
Natürlich ist dies nur ein Beispiel dafür, wie Sie von der Fähigkeit von ClusterControl profitieren können, Ihre MySQL-Datenbanken zu überwachen und zu verwalten, während Sie gleichzeitig die Fähigkeit von Vitess nutzen können, die Daten zu skalieren und zu fragmentieren. Vitess ist ein großartiges Tool, aber es fehlen ein paar Elemente. Glücklicherweise kann Ihnen ClusterControl in solchen Fällen helfen.
