För alla som inte är bekanta med Vitess är det ett MySQL-baserat databassystem som är avsett att leverera ett lättskaligt, sönderklippt, relationsdatabashanteringssystem. Vi kommer inte att gå in på detaljer om designen, men kort sagt, Vitess består av proxynoder som dirigerar förfrågningarna, gateways som hanterar databasnoderna och slutligen själva MySQL-databasnoderna, som är avsedda att lagra data. Om vi pratar om MySQL kan man fundera på om det finns en möjlighet att faktiskt använda externa verktyg som till exempel ClusterControl för att hantera de underliggande databaserna. Det korta svaret är "ja". Längre svar blir det här blogginlägget.
MySQL i Vitess
Först och främst vill vi ägna lite tid åt att prata om hur Vitess använder MySQL. Arkitekturen på hög nivå beskrivs på Vitess dokumentationssida. Kort och gott har vi VTGate som fungerar som proxy, vi har en Topology Service som är en metadatabutik baserad på Zookeeper, Consul eller Etcd, där all information om noderna i systemet finns, äntligen har vi VTTablets, som agerar som mellanhand mellan VTGate och MySQL-instans. MySQL-instanser kan vara fristående eller så kan de konfigureras med standard asynkron (eller semisynkron) replikering. MySQL används för att lagra data. Data kan delas upp i skärvor, i så fall kommer en MySQL-instans att innehålla en delmängd av datan.
Allt detta fungerar utmärkt. Vitess kan bestämma vilken nod som är mastern, vilka noder som är slavar och dirigerar frågor i enlighet med detta. Det finns dock flera problem. Inte alla de mest grundläggande funktionerna levereras av Vitess. Topologidetektering och frågedirigering, ja. Säkerhetskopiering - ja också, Vitess kan konfigureras för att ta säkerhetskopior av data och låta användare återställa allt som har säkerhetskopierats. Tyvärr finns det inget internt stöd för automatisk failover. Det finns inget riktigt trendigt användargränssnitt som skulle hjälpa användare att förstå databasernas tillstånd och deras arbetsbelastning. Lyckligtvis, eftersom vi talar om standard MySQL, kan vi enkelt använda externa lösningar för att åstadkomma detta. Till exempel, för failover, kan Vitess integreras med Orchestrator. Låt oss ta en titt på hur ClusterControl kan användas tillsammans med Vitess för att tillhandahålla hantering, övervakning och failover.
Distribuera ett nytt databaskluster med ClusterControl
Låt oss först implementera ett nytt kluster. Som vanligt med ClusterControl måste du tillhandahålla hårdvara och se till att ClusterControl kan komma åt dessa noder med SSH.
Först måste vi definiera SSH-anslutning.
Närnäst väljer vi leverantör och version. Enligt dokumentationen stöder Vitess MySQL och Percona Server i versionerna 5.7 och 8.0 (även om den inte stöder metoden caching_sha2_password så du måste vara försiktig när du skapar användare). Den stöder också MariaDB upp till 10.3.
Slutligen definierar vi topologin. Efter att ha klickat på "Deploy" kommer ClusterControl att utföra klusterdistributionen.
När det är klart bör du se klustret och du bör kunna hantera det med ClusterControl. Om automatisk återställning för kluster och nod är aktiverade kommer ClusterControl att utföra automatiska failovers om det skulle behövas.
Du kommer också att dra nytta av agentbaserad övervakning i avsnittet "Dashboard" i ClusterControl UI.
Importerar klustret till Vitess
Som nästa steg bör vi ha Vitess utplacerat. Det vi beskriver här är inte på något sätt en installation av produktionsklass, därför kommer vi att skära ner några hörn och bara distribuera Vitess-sviten på en enda nod efter handledningen från Vitess-dokumentationen. För att göra det lättare att hantera, kommer vi att gå med lokal installationsguide, som kommer att distribuera alla tjänster, tillsammans med exempeldatabaser på en enda nod. Gör den tillräckligt stor för att rymma dem. För teständamål bör en nod med ett par CPU-kärnor och 4 GB minne räcka.
Låt oss anta att allt gick bra och att du har en lokal Vitess-distribution som körs på noden. Nästa steg blir att importera vårt kluster som distribueras av ClusterControl till Vitess. För det måste vi köra ytterligare två VTT-tabletter. Först ska vi skapa kataloger för dessa VTT-tabletter:
[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_0000000402Sedan, på databasen, kommer vi att skapa en användare som kommer att användas för Vitess att ansluta och hantera 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)Om vi vill kanske vi också vill skapa fler användare. Vitess tillåter oss att skicka ett par användare med olika åtkomstbehörigheter:applikationsanvändare, DBA-användare, replikeringsanvändare, fullständigt privilegierad användare och ett par till.
Det sista vi måste göra är att inaktivera super_read_only på alla MySQL noder som Vitess kommer att försöka skapa metadata på repliken, vilket resulterar i ett misslyckat försök att starta vttablet-tjänsten.
När detta är gjort bör vi starta VTTablets. I båda fallen måste vi se till att portarna är unika och att vi skickar korrekta referenser för att komma åt databasinstansen:
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 är klar kan vi kontrollera hur Vitess ser på de nya VTT-surfplattorna:
[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 finns där men båda rapporteras som repliker av Vitess. Vi kan nu trigga Vitess att kontrollera topologin för vår riktiga master (nod som vi importerade med ID 401)
[email protected]:~/my-vitess-example$ vtctlclient TabletExternallyReparented zone1-401Nu ser allt korrekt ut:
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)Integrera ClusterControl automatiserad failover i Vitess
Den sista biten vi vill ta en titt på är den automatiska failover-hanteringen med ClusterControl och se hur du kan integrera den med Vitess. Det kommer att vara ganska likt det vi just har sett. Det största problemet att hantera är att failover inte ändrar någonting i Vitess. Lösningen är vad vi har använt tidigare, TabletExternallyReparented-kommandot. Den enda utmaningen är att utlösa den när failover inträffar. Lyckligtvis kommer ClusterControl med krokar som låter oss ansluta till failover-processen. Vi kommer att använda dem för att köra vtctlclienten. Det måste dock installeras på ClusterControl-instansen först. Det enklaste sättet att åstadkomma det är bara genom att kopiera binären från Vitess-instansen till ClusterControl.
Låt oss först skapa katalogen på ClusterControl-noden:
mkdir -r /usr/local/vitess/binKopiera sedan bara filen:
scp /usr/local/vitess/bin/vtctlclient [email protected]:/usr/local/vitess/bin/Som ett nästa steg måste vi skapa ett skript som kommer att köra kommandot för att återskapa shards. Vi kommer att använda replication_post_failover_script och replication_post_switchover_script. Cmon kommer att köra skriptet med flera argument. Vi är intresserade av den tredje av dem, den kommer att innehålla värdnamnet för masterkandidaten - noden som har valts ut som en ny master.
Exempelskriptet kan se ut ungefär så här.
#!/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}Tänk på att detta bara är ett minimum som fungerar. Du bör implementera ett mer detaljerat skript som kanske kommer att utföra ytterligare hälsokontroller. Istället för att hårdkoda värdnamnen och surfplattornas namn kan du faktiskt fråga ClusterControl för att få listan över noder i klustret, sedan kanske du vill jämföra den med innehållet i Topology Service för att se vilket surfplattealias som ska användas.
När vi är redo med skriptet bör vi konfigurera det för att köras av ClusterControl:
Vi kan testa detta genom att manuellt marknadsföra repliken. Det ursprungliga tillståndet, som sett av 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 är intresserade av tangentrymden 'clustercontrol'. 401 (10.0.0.181) var master och 402 (10.0.0.182) var repliken.
Vi kan marknadsföra 10.0.0.182 för att bli en ny mästare. Jobbet startar och vi kan se att vårt skript kördes:
Äntligen är jobbet slutfört:
Allt gick bra i ClusterControl. Låt oss ta en titt 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 är allt ok här också. 402 är den nya mastern och 401 är markerad som repliken.
Det här är naturligtvis bara ett exempel på hur du kan dra nytta av ClusterControls förmåga att övervaka och hantera dina MySQL-databaser samtidigt som du kan utnyttja Vitess förmåga att skala ut och skära data. Vitess är ett bra verktyg men det saknar ett par element. Lyckligtvis kan ClusterControl säkerhetskopiera dig i dessa fall.