Pro všechny, kteří nejsou obeznámeni s Vitess, je to databázový systém založený na MySQL, který je určen k poskytování snadno škálovatelného systému správy relačních databází. Nebudeme se pouštět do podrobností o designu, ale stručně řečeno, Vites se skládá z proxy uzlů, které směrují požadavky, bran spravujících databázové uzly a nakonec samotných databázových uzlů MySQL, které jsou určeny k ukládání dat. Pokud mluvíme o MySQL, lze si myslet, že existuje možnost skutečně používat externí nástroje, jako je například ClusterControl, ke správě těchto základních databází. Krátká odpověď je „ano“. Delší odpovědí bude tento blogový příspěvek.
MySQL ve Vitess
Za prvé, chceme strávit trochu času povídáním o tom, jak Vites používá MySQL. Architektura vysoké úrovně je popsána na stránce dokumentace Vites. Stručně řečeno, máme VTGate, který funguje jako proxy, máme Topology Service, což je úložiště metadat založené na Zookeeper, Consul nebo Etcd, kde jsou umístěny všechny informace o uzlech v systému, konečně máme VTTtablety, které fungují jako prostředník mezi VTGate a MySQL instancí. Instance MySQL mohou být samostatné nebo je lze konfigurovat pomocí standardní asynchronní (nebo semisynchronní) replikace. K ukládání dat se používá MySQL. Data lze rozdělit na části, v takovém případě bude instance MySQL obsahovat podmnožinu dat.
To vše funguje skvěle. Vites je schopen určit, který uzel je master, které uzly jsou podřízené, a podle toho směrovat dotazy. Existuje však několik problémů. Vites neposkytuje všechny nejzákladnější funkce. Detekce topologie a směrování dotazů ano. Zálohy – ano, také Vites lze nakonfigurovat tak, aby zálohoval data a umožnil uživatelům obnovit vše, co bylo zálohováno. Bohužel neexistuje žádná interní podpora pro automatické převzetí služeb při selhání. Neexistuje žádné správné uživatelské rozhraní trendů, které by uživatelům pomohlo porozumět stavu databází a jejich pracovní zátěži. Naštěstí, protože mluvíme o standardním MySQL, můžeme k tomu snadno použít externí řešení. Například pro převzetí služeb při selhání lze Vites integrovat s Orchestratorem. Pojďme se podívat na to, jak lze ClusterControl použít ve spojení s Vites k zajištění správy, monitorování a převzetí služeb při selhání.
Nasazení nového databázového clusteru pomocí ClusterControl
Nejprve nechejte nasadit nový cluster. Jako obvykle u ClusterControl musíte zajistit hardware a zajistit, aby ClusterControl mohl přistupovat k těmto uzlům pomocí SSH.
Nejprve musíme definovat připojení SSH.
Dále vybereme dodavatele a verzi. Podle dokumentace Vites podporuje MySQL a Percona Server ve verzích 5.7 a 8.0 (ačkoli nepodporuje metodu caching_sha2_password, takže musíte být opatrní při vytváření uživatelů). Podporuje také MariaDB až do 10.3.
Nakonec definujeme topologii. Po kliknutí na „Deploy“ provede ClusterControl nasazení clusteru.
Jakmile bude připraven, měli byste vidět cluster a měli byste být schopni spravovat pomocí ClusterControl. Pokud je povolena funkce Auto Recovery for Cluster a Node, ClusterControl v případě potřeby provede automatická převzetí služeb při selhání.
Budete také těžit z monitorování založeného na agentech v sekci „Dashboard“ uživatelského rozhraní ClusterControl.
Importování clusteru do Vitess
Jako další krok bychom měli nasadit Vites. To, co zde popisujeme, není v žádném případě nastavení na produkční úrovni, proto se chystáme omezit některé rohy a pouze nasadit sadu Vites na jeden uzel podle návodu z dokumentace Vites. Abychom si s tím usnadnili řešení, použijeme průvodce místní instalací, který nasadí všechny služby spolu s ukázkovými databázemi na jeden uzel. Udělejte to dostatečně velké, aby se do nich vešly. Pro testovací účely by měl stačit uzel s několika jádry CPU a 4 GB paměti.
Předpokládejme, že vše proběhlo v pořádku a na uzlu běží místní nasazení Vites. Dalším krokem bude import našeho clusteru nasazeného ClusterControl do Vites. K tomu musíme spustit další dva VTTtablety. Nejprve vytvoříme adresáře pro tyto tablety VTT:
[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_0000000402Potom v databázi vytvoříme uživatele, kterého bude Vites používat k připojení a správě databáze.
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)Pokud chceme, můžeme také chtít vytvořit více uživatelů. Vites nám umožňuje předat několik uživatelů s různými přístupovými právy:uživatele aplikace, uživatele DBA, uživatele replikace, plně privilegovaného uživatele a několik dalších.
Poslední věc, kterou musíme udělat, je zakázat super_read_only na všech MySQL uzly, protože Vites se pokusí vytvořit metadata na replice, což povede k neúspěšnému pokusu o spuštění služby vttablet.
Jakmile to uděláme, měli bychom spustit VTTablets. V obou případech musíme zajistit, že porty jsou jedinečné a že předáme správná pověření pro přístup k instanci databáze:
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 &Jakmile bude připraven, můžeme zkontrolovat, jak Vites vidí nové tablety VTT:
[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)Uzly existují, ale oba jsou hlášeny jako repliky Vitesem. Nyní můžeme spustit Vites, aby zkontroloval topologii pro náš skutečný master (uzel, který jsme importovali s ID 401)
[email protected]:~/my-vitess-example$ vtctlclient TabletExternallyReparented zone1-401Nyní vše vypadá správně:
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)Integrace automatického převzetí služeb při selhání ClusterControl do systému Vites
Posledním bodem, na který se chceme podívat, je automatizované zpracování převzetí služeb při selhání pomocí ClusterControl a uvidíme, jak jej můžete integrovat s Vitess. Bude to dost podobné tomu, co jsme právě viděli. Hlavním problémem, který je třeba řešit, je to, že převzetí služeb při selhání ve Vitess nic nemění. Řešením je to, co jsme použili dříve, příkaz TabletExternallyReparented. Jediným problémem je spustit jej, když dojde k převzetí služeb při selhání. Naštěstí ClusterControl přichází s háčky, které nám umožňují zapojit se do procesu převzetí služeb při selhání. Použijeme je ke spuštění vtctlclient. Nejprve je však nutné jej nainstalovat do instance ClusterControl. Nejjednodušší způsob, jak toho dosáhnout, je zkopírovat binární soubor z instance Vites do ClusterControl.
Nejprve vytvořte adresář v uzlu ClusterControl:
mkdir -r /usr/local/vitess/binPak zkopírujte soubor:
scp /usr/local/vitess/bin/vtctlclient [email protected]:/usr/local/vitess/bin/Jako další krok musíme vytvořit skript, který provede příkaz k reparentu shardů. Použijeme replication_post_failover_script a replication_post_switchover_script. Cmon spustí skript s několika argumenty. Zajímá nás třetí z nich, bude obsahovat jméno hostitele hlavního kandidáta - uzel, který byl vybrán jako nový master.
Ukázkový skript může vypadat nějak takto.
#!/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}Mějte prosím na paměti, že toto je jen naprosté minimum, které funguje. Měli byste implementovat podrobnější skript, který provede možná další kontroly zdravého rozumu. Namísto pevného kódování názvů hostitelů a názvů tabletů můžete ve skutečnosti dotazovat ClusterControl, abyste získali seznam uzlů v clusteru, pak jej možná budete chtít porovnat s obsahem Topology Service a zjistit, který alias tabletu by měl být použit.
Jakmile jsme připraveni se skriptem, měli bychom jej nakonfigurovat tak, aby jej spouštěl ClusterControl:
Můžeme to otestovat ruční propagací repliky. Počáteční stav, jak jej viděl Vites, byl:
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)Zajímá nás klíčový prostor „clustercontrol“. 401 (10.0.0.181) byla hlavní a 402 (10.0.0.182) byla replika.
Můžeme povýšit 10.0.0.182 na nového mistra. Úloha se spustí a my vidíme, že náš skript byl proveden:
Úloha je konečně dokončena:
V ClusterControl šlo vše dobře. Pojďme se podívat na 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)Jak vidíte, i zde je vše v pořádku. 402 je nová hlavní a 401 je označena jako replika.
Toto je samozřejmě jen příklad toho, jak můžete těžit ze schopnosti ClusterControl monitorovat a spravovat vaše databáze MySQL a přitom stále využívat schopnost Vites škálovat a skartovat data. Vites je skvělý nástroj, ale postrádá několik prvků. Naštěstí vás ClusterControl může v těchto případech zálohovat.