Voor iedereen die niet bekend is met Vitess, het is een op MySQL gebaseerd databasesysteem dat bedoeld is om een eenvoudig te schalen, sharded, relationeel databasebeheersysteem te leveren. We zullen niet ingaan op details over het ontwerp, maar kort gezegd, Vitess bestaat uit proxy-knooppunten die de verzoeken routeren, gateways die de database-knooppunten beheren en, ten slotte, MySQL-databaseknooppunten zelf, die bedoeld zijn om de gegevens op te slaan. Als we het over MySQL hebben, zou je kunnen denken dat er een optie is om daadwerkelijk externe tools zoals bijvoorbeeld ClusterControl te gebruiken om die onderliggende databases te beheren. Het korte antwoord is "ja". Een langer antwoord zal deze blogpost zijn.
MySQL in Vitess
Allereerst willen we wat tijd besteden aan het praten over hoe Vitess MySQL gebruikt. De architectuur op hoog niveau wordt beschreven op de documentatiepagina van Vitess. Kortom, we hebben VTGate die als een proxy fungeert, we hebben een Topology Service, een metadata-opslag op basis van Zookeeper, Consul of Etcd, waar alle informatie over de knooppunten in het systeem zich bevindt, ten slotte hebben we VTTablets, die werken als tussenpersoon tussen VTGate en MySQL-instantie. MySQL-instanties kunnen standalone zijn of ze kunnen worden geconfigureerd met behulp van standaard asynchrone (of semi-synchrone) replicatie. MySQL wordt gebruikt om gegevens op te slaan. Gegevens kunnen worden opgesplitst in shards, in dat geval bevat een MySQL-instantie een subset van de gegevens.
Dit werkt allemaal prima. Vitess kan bepalen welk knooppunt de master is en welke knooppunten slaven zijn en de query's dienovereenkomstig routeren. Er zijn echter verschillende problemen. Niet alle meest elementaire functionaliteit wordt geleverd door Vitess. Topologiedetectie en queryrouting, ja. Back-ups - ja ook, Vitess kan worden geconfigureerd om back-ups van de gegevens te maken en gebruikers in staat te stellen alles te herstellen waarvan een back-up is gemaakt. Helaas is er geen interne ondersteuning voor automatische failover. Er is geen goede gebruikersinterface voor trends die gebruikers zou helpen de status van de databases en hun werklast te begrijpen. Gelukkig kunnen we, aangezien we het hebben over standaard MySQL, gemakkelijk externe oplossingen gebruiken om dit te bereiken. Voor failover kan Vitess bijvoorbeeld worden geïntegreerd met Orchestrator. Laten we eens kijken hoe ClusterControl kan worden gebruikt in combinatie met Vitess voor beheer, monitoring en failover.
Een nieuw databasecluster implementeren met ClusterControl
Laten we eerst een nieuw cluster implementeren. Zoals gebruikelijk bij ClusterControl, moet u hardware inrichten en ervoor zorgen dat ClusterControl toegang heeft tot die knooppunten met behulp van SSH.
Eerst moeten we SSH-connectiviteit definiëren.
Vervolgens kiezen we de leverancier en versie. Volgens de documentatie ondersteunt Vitess MySQL en Percona Server in versies 5.7 en 8.0 (hoewel het de caching_sha2_password-methode niet ondersteunt, dus je moet voorzichtig zijn bij het maken van gebruikers). Het ondersteunt ook MariaDB tot 10.3.
Ten slotte definiëren we de topologie. Nadat u op "Deploy" hebt geklikt, voert ClusterControl de clusterimplementatie uit.
Zodra het klaar is, zou u het cluster moeten zien en zou u beheer het met ClusterControl. Als Auto Recovery voor Cluster en Node zijn ingeschakeld, voert ClusterControl indien nodig automatische failovers uit.
U profiteert ook van agentgebaseerde monitoring in het gedeelte 'Dashboard' van de gebruikersinterface van ClusterControl.
Het cluster importeren naar Vitess
Als volgende stap zouden we Vitess moeten inzetten. Wat we hier beschrijven, is geenszins een setup van productiekwaliteit, daarom gaan we een paar bochten nemen en Vitess-suite implementeren op een enkel knooppunt volgens de tutorial uit de Vitess-documentatie. Om het gemakkelijker te maken om ermee om te gaan, gebruiken we de Local Install-gids, die alle services zal implementeren, samen met voorbeelddatabases op een enkel knooppunt. Maak het groot genoeg om ze te huisvesten. Voor testdoeleinden zou een node met een paar CPU-cores en 4 GB geheugen voldoende moeten zijn.
Laten we aannemen dat alles prima is verlopen en dat er een lokale Vitess-implementatie op het knooppunt draait. De volgende stap is het importeren van ons door ClusterControl geïmplementeerde cluster in Vitess. Daarvoor moeten we nog twee VTTablets draaien. Eerst zullen we mappen maken voor die VTTablets:
[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_0000000402Vervolgens gaan we in de database een gebruiker maken die door Vitess wordt gebruikt om verbinding te maken met de database en deze te beheren.
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)Als we willen, willen we misschien ook meer gebruikers maken. Met Vitess kunnen we een aantal gebruikers met verschillende toegangsrechten doorgeven:applicatiegebruiker, DBA-gebruiker, replicatiegebruiker, volledig bevoorrechte gebruiker en nog een paar meer.
Het laatste wat we moeten doen is de super_read_only uitschakelen op alle MySQL nodes, aangezien Vitess zal proberen metadata op de replica te maken, wat resulteert in een mislukte poging om de vttablet-service te starten.
Zodra dit gedaan is, zouden we VTTablets moeten starten. In beide gevallen moeten we ervoor zorgen dat de poorten uniek zijn en dat we de juiste inloggegevens doorgeven om toegang te krijgen tot de database-instantie:
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 &Zodra het klaar is, kunnen we controleren hoe Vitess de nieuwe VTTablets ziet:
[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)Nodes zijn er, maar beide worden door Vitess gerapporteerd als replica's. We kunnen nu Vitess activeren om de topologie voor onze echte master te controleren (knooppunt dat we hebben geïmporteerd met ID van 401)
[email protected]:~/my-vitess-example$ vtctlclient TabletExternallyReparented zone1-401Nu ziet alles er goed uit:
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)Integreren van ClusterControl geautomatiseerde failover in Vitess
Het laatste waar we naar willen kijken is de geautomatiseerde failover-afhandeling met ClusterControl en kijken hoe je deze kunt integreren met Vitess. Het zal vrij gelijkaardig zijn aan wat we zojuist hebben gezien. Het grootste probleem om mee om te gaan is dat de failover niets verandert in de Vitess. De oplossing is wat we eerder hebben gebruikt, de opdracht TabletExternallyReparented. De enige uitdaging is om het te activeren wanneer de failover plaatsvindt. Gelukkig wordt ClusterControl geleverd met hooks waarmee we kunnen aansluiten op het failover-proces. We zullen ze gebruiken om de vtctlclient uit te voeren. Het moet echter eerst op de ClusterControl-instantie worden geïnstalleerd. De eenvoudigste manier om dat te bereiken is door het binaire bestand van de Vitess-instantie naar ClusterControl te kopiëren.
Laten we eerst de directory op het ClusterControl-knooppunt maken:
mkdir -r /usr/local/vitess/binKopieer dan het bestand:
scp /usr/local/vitess/bin/vtctlclient [email protected]:/usr/local/vitess/bin/Als volgende stap moeten we een script maken dat de opdracht uitvoert om shards te reparenten. We zullen replication_post_failover_script en replication_post_switchover_script gebruiken. Cmon voert het script uit met verschillende argumenten. We zijn geïnteresseerd in de derde ervan, deze zal de hostnaam van de masterkandidaat bevatten - het knooppunt dat is gekozen als een nieuwe master.
Het voorbeeldscript kan er ongeveer zo uitzien.
#!/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}Houd er rekening mee dat dit slechts een absoluut minimum is dat werkt. Je zou een meer gedetailleerd script moeten implementeren dat misschien extra sanity checks zal uitvoeren. In plaats van de hostnamen en tabletnamen hard te coderen, kunt u ClusterControl opvragen om de lijst met knooppunten in het cluster te krijgen, en deze vervolgens vergelijken met de inhoud van de Topology Service om te zien welke tabletalias moet worden gebruikt.
Zodra we klaar zijn met het script, moeten we het configureren om te worden uitgevoerd door ClusterControl:
We kunnen dit testen door de replica handmatig te promoten. De oorspronkelijke staat, zoals gezien door Vitess, was:
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)We zijn geïnteresseerd in 'clustercontrol' keyspace. 401 (10.0.0.181) was de meester en 402 (10.0.0.182) was de replica.
We kunnen 10.0.0.182 promoten om een nieuwe master te worden. De taak begint en we kunnen zien dat ons script is uitgevoerd:
Eindelijk is de taak voltooid:
Alles ging goed in ClusterControl. Laten we eens kijken naar 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)Zoals je kunt zien, is hier ook alles in orde. 402 is de nieuwe master en 401 is gemarkeerd als de replica.
Dit is natuurlijk slechts een voorbeeld van hoe u kunt profiteren van de mogelijkheid van ClusterControl om uw MySQL-databases te bewaken en te beheren, terwijl u toch gebruik kunt maken van het vermogen van Vitess om de gegevens uit te schalen en te sharden. Vitess is een geweldig hulpmiddel, maar het mist een aantal elementen. Gelukkig kan ClusterControl in die gevallen een back-up van je maken.