For alle, der ikke er fortrolige med Vitess, er det et MySQL-baseret databasesystem, der er beregnet til at levere et let-skaleret, sønderdelt, relationelt databasestyringssystem. Vi kommer ikke nærmere ind på designet, men kort fortalt består Vitess af proxy-noder, der dirigerer anmodningerne, gateways, der administrerer databasenoderne, og endelig MySQL-databasenoder selv, som er beregnet til at lagre dataene. Hvis vi taler om MySQL, kan man tænke på, om der er en mulighed for faktisk at bruge eksterne værktøjer som for eksempel ClusterControl til at administrere de underliggende databaser. Det korte svar er "ja". Længere svar vil være dette blogindlæg.
MySQL i Vitess
Først og fremmest vil vi bruge lidt tid på at tale om, hvordan Vitess bruger MySQL. Arkitekturen på højt niveau er beskrevet på Vitess dokumentationsside. Kort fortalt har vi VTGate der fungerer som proxy, vi har en Topology Service som er et metadatalager baseret på Zookeeper, Consul eller Etcd, hvor alle informationer om noderne i systemet er placeret, endelig har vi VTTablets, som fungerer som mellemmand mellem VTGate og MySQL instans. MySQL-instanser kan være selvstændige, eller de kan konfigureres ved hjælp af standard asynkron (eller semisynkron) replikering. MySQL bruges til at gemme data. Data kan opdeles i shards, i så fald vil en MySQL-instans indeholde en delmængde af dataene.
Alt dette fungerer godt. Vitess er i stand til at bestemme, hvilken node der er master, hvilke noder der er slaver, og dirigerer forespørgsler i overensstemmelse hermed. Der er dog flere problemer. Ikke al den mest basale funktionalitet leveres af Vitess. Topologidetektion og forespørgselsrouting, ja. Sikkerhedskopier - ja også, Vitess kan konfigureres til at tage sikkerhedskopier af dataene og give brugerne mulighed for at gendanne, hvad der er blevet sikkerhedskopieret. Desværre er der ingen intern support til automatiseret failover. Der er ingen ordentlig trending UI, der vil hjælpe brugerne med at forstå databasernes tilstand og deres arbejdsbyrde. Heldigvis, da vi taler om standard MySQL, kan vi nemt bruge eksterne løsninger til at opnå dette. For eksempel til failover kan Vitess integreres med Orchestrator. Lad os tage et kig på, hvordan ClusterControl kan bruges sammen med Vitess til at levere administration, overvågning og failover.
Implementering af en ny databaseklynge ved hjælp af ClusterControl
Først, lad os få installeret en ny klynge. Som sædvanligt med ClusterControl skal du klargøre hardware og sikre, at ClusterControl kan få adgang til disse noder ved hjælp af SSH.
Først skal vi definere SSH-forbindelse.
Derefter vælger vi leverandør og version. Ifølge dokumentationen understøtter Vitess MySQL og Percona Server i version 5.7 og 8.0 (selvom den ikke understøtter caching_sha2_password-metoden, så du skal være forsigtig, når du opretter brugere). Det understøtter også MariaDB op til 10.3.
Til sidst definerer vi topologien. Efter at have klikket på "Deploy", vil ClusterControl udføre klyngeimplementeringen.
Når den er klar, bør du se klyngen, og du bør være i stand til at administrere det ved hjælp af ClusterControl. Hvis Auto Recovery for Cluster og Node er aktiveret, vil ClusterControl udføre automatiske failovers, hvis det er nødvendigt.
Du vil også drage fordel af agentbaseret overvågning i afsnittet "Dashboard" af ClusterControl UI.
Importerer klyngen til Vitess
Som et næste skridt bør vi have Vitess implementeret. Det, vi beskriver her, er på ingen måde en opsætning i produktionskvalitet, derfor vil vi skære nogle hjørner og bare implementere Vitess suite på en enkelt node efter vejledningen fra Vitess-dokumentationen. For at gøre det nemmere at håndtere, vil vi gå med den lokale installationsvejledning, som vil implementere alle tjenesterne sammen med eksempeldatabaser på en enkelt node. Gør den stor nok til at rumme dem. Til testformål burde en node med et par CPU-kerner og 4 GB hukommelse være nok.
Lad os antage, at alt gik fint, og at du har en lokal Vitess-implementering kørende på noden. Det næste trin vil være at importere vores klynge implementeret af ClusterControl til Vitess. Til det skal vi køre yderligere to VTT-tablets. Først skal vi oprette mapper til disse VTT-tablets:
[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_0000000402Derefter, på databasen, vil vi oprette en bruger, som vil blive brugt til Vitess til at forbinde og administrere databasen.
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)Hvis vi vil, vil vi måske også oprette flere brugere. Vitess giver os mulighed for at videregive et par brugere med forskellige adgangsrettigheder:applikationsbruger, DBA-bruger, replikeringsbruger, fuldt privilegeret bruger og et par mere.
Det sidste vi skal gøre er at deaktivere super_read_only på alle MySQL noder som Vitess vil forsøge at oprette metadata på replikaen, hvilket resulterer i et mislykket forsøg på at starte vttablet-tjenesten.
Når dette er gjort, bør vi starte VTTablets. I begge tilfælde skal vi sikre, at portene er unikke, og at vi sender korrekte legitimationsoplysninger for at få adgang til databaseinstansen:
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 &Når den er klar, kan vi tjekke, hvordan Vitess ser de nye VTT-tablets:
[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)Noder er der, men begge rapporteres som replikaer af Vitess. Vi kan nu udløse Vitess til at tjekke topologien for vores rigtige mester (node, som vi importerede med ID 401)
[email protected]:~/my-vitess-example$ vtctlclient TabletExternallyReparented zone1-401Nu ser alt korrekt ud:
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 af ClusterControl automatiseret failover i Vitess
Den sidste bit, vi vil tage et kig på, er den automatiske failover-håndtering med ClusterControl og se, hvordan du kan integrere det med Vitess. Det vil være ret lig det, vi lige har set. Det største problem at håndtere er, at failoveren ikke ændrer noget i Vitess. Løsningen er, hvad vi har brugt tidligere, TabletExternallyReparented-kommandoen. Den eneste udfordring er at udløse den, når failoveren sker. Heldigvis kommer ClusterControl med kroge, der giver os mulighed for at tilslutte til failover-processen. Vi bruger dem til at køre vtctlclienten. Det skal dog først installeres på ClusterControl-instansen. Den nemmeste måde at opnå det på er blot ved at kopiere det binære fra Vitess-instansen til ClusterControl.
Lad os først oprette mappen på ClusterControl-noden:
mkdir -r /usr/local/vitess/binSå skal du bare kopiere filen:
scp /usr/local/vitess/bin/vtctlclient [email protected]:/usr/local/vitess/bin/Som et næste trin er vi nødt til at oprette et script, der udfører kommandoen for at genforælde shards. Vi vil bruge replication_post_failover_script og replication_post_switchover_script. Cmon vil udføre scriptet med flere argumenter. Vi er interesserede i den tredje af dem, den vil indeholde værtsnavnet på masterkandidaten - den node, der er blevet valgt som en ny master.
Eksempelscriptet kan se nogenlunde sådan ud.
#!/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}Husk venligst, at dette kun er et minimum, der virker. Du bør implementere et mere detaljeret script, der muligvis vil udføre yderligere sundhedstjek. I stedet for at hardkode værtsnavnene og tabletnavnene kan du faktisk forespørge ClusterControl for at få listen over noder i klyngen, så vil du måske sammenligne den med indholdet af Topology Service for at se, hvilket tablet-alias der skal bruges.
Når vi er klar med scriptet, bør vi konfigurere det til at blive eksekveret af ClusterControl:
Vi kan teste dette ved manuelt at promovere replikaen. Den oprindelige tilstand, set af Vitess, var:
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)Vi er interesserede i 'clustercontrol'-tasterum. 401 (10.0.0.181) var master og 402 (10.0.0.182) var replikaen.
Vi kan promovere 10.0.0.182 til at blive en ny mester. Job starter, og vi kan se, at vores script blev udført:
Endelig er opgaven fuldført:
Alt gik godt i ClusterControl. Lad os tage et kig på 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)Som du kan se, er alt også ok her. 402 er den nye master og 401 er markeret som replikaen.
Selvfølgelig er dette blot et eksempel på, hvordan du kan drage fordel af ClusterControls evne til at overvåge og administrere dine MySQL-databaser, mens du stadig er i stand til at udnytte Vitess' evne til at skalere ud og sønderdele dataene. Vitess er et fantastisk værktøj, men det mangler et par elementer. Heldigvis kan ClusterControl sikkerhedskopiere dig i disse tilfælde.