Dla wszystkich, którzy nie są zaznajomieni z Vitess, jest to system baz danych oparty na MySQL, który ma na celu dostarczenie łatwego do skalowania, podzielonego na fragmenty, relacyjnego systemu zarządzania bazą danych. Nie będziemy wchodzić w szczegóły dotyczące projektu, ale w skrócie, Vitess składa się z węzłów proxy, które kierują żądania, bram zarządzających węzłami bazy danych i wreszcie samych węzłów bazy danych MySQL, które są przeznaczone do przechowywania danych. Jeśli mówimy o MySQL, można pomyśleć, czy istnieje możliwość wykorzystania zewnętrznych narzędzi, takich jak na przykład ClusterControl, do zarządzania bazami danych. Krótka odpowiedź brzmi „tak”. Dłuższą odpowiedzią będzie ten post na blogu.
MySQL w Vitess
Przede wszystkim chcemy poświęcić trochę czasu na rozmowę o tym, jak Vitess używa MySQL. Architektura wysokiego poziomu jest opisana na stronie dokumentacji Vitess. W skrócie mamy VTGate, który działa jako proxy, mamy Topology Service czyli magazyn metadanych oparty na Zookeeper, Consul lub Etcd, gdzie znajdują się wszystkie informacje o węzłach w systemie, wreszcie mamy VTTablety, które działają jako pośrednik między instancjami VTGate i MySQL. Instancje MySQL mogą być autonomiczne lub mogą być konfigurowane przy użyciu standardowej replikacji asynchronicznej (lub półsynchronicznej). MySQL służy do przechowywania danych. Dane można podzielić na fragmenty, w takim przypadku instancja MySQL będzie zawierać podzbiór danych.
Wszystko to działa świetnie. Vitess jest w stanie określić, który węzeł jest nadrzędnym, a które podrzędnym, odpowiednio kierując zapytania. Jest jednak kilka problemów. Nie wszystkie podstawowe funkcje są dostarczane przez Vitess. Wykrywanie topologii i routing zapytań, tak. Kopie zapasowe - tak, Vitess można skonfigurować tak, aby robił kopie zapasowe danych i umożliwiał użytkownikom przywracanie tego, co zostało zarchiwizowane. Niestety, nie ma wewnętrznej obsługi automatycznego przełączania awaryjnego. Nie ma odpowiedniego interfejsu użytkownika trendów, który pomógłby użytkownikom zrozumieć stan baz danych i ich obciążenie. Na szczęście, ponieważ mówimy o standardowym MySQL, możemy łatwo wykorzystać do tego zewnętrzne rozwiązania. Na przykład w przypadku przełączania awaryjnego Vitess można zintegrować z programem Orchestrator. Przyjrzyjmy się, jak ClusterControl może być używany w połączeniu z Vitess w celu zapewnienia zarządzania, monitorowania i przełączania awaryjnego.
Wdrażanie nowego klastra bazy danych za pomocą ClusterControl
Najpierw wdrożmy nowy klaster. Jak zwykle w przypadku ClusterControl, musisz zapewnić sprzęt i upewnić się, że ClusterControl może uzyskać dostęp do tych węzłów za pomocą SSH.
Najpierw musimy zdefiniować łączność SSH.
Następnie wybierzemy dostawcę i wersję. Zgodnie z dokumentacją Vitess obsługuje MySQL i Percona Server w wersjach 5.7 i 8.0 (choć nie obsługuje metody caching_sha2_password, więc trzeba być ostrożnym przy tworzeniu użytkowników). Obsługuje również MariaDB do 10.3.
Na koniec definiujemy topologię. Po kliknięciu „Wdróż”, ClusterControl wykona instalację klastra.
Gdy będzie gotowy, powinieneś zobaczyć klaster i powinieneś być w stanie zarządzać nim za pomocą ClusterControl. Jeśli włączone jest automatyczne przywracanie klastra i węzła, ClusterControl wykona automatyczne przełączanie awaryjne, jeśli zajdzie taka potrzeba.
Skorzystasz również z monitorowania agentowego w sekcji „Pulpit nawigacyjny” interfejsu ClusterControl.
Importowanie klastra do Vitess
W następnym kroku powinniśmy wdrożyć Vitess. To, co tutaj opisujemy, w żadnym wypadku nie jest konfiguracją klasy produkcyjnej, dlatego zamierzamy pójść na skróty i po prostu wdrożyć pakiet Vitess na jednym węźle zgodnie z samouczkiem z dokumentacji Vitess. Aby łatwiej sobie z tym poradzić, skorzystamy z przewodnika po instalacji lokalnej, który wdroży wszystkie usługi wraz z przykładowymi bazami danych na jednym węźle. Spraw, aby był wystarczająco duży, aby je pomieścić. Do celów testowych powinien wystarczyć węzeł z kilkoma rdzeniami procesora i 4 GB pamięci.
Załóżmy, że wszystko poszło dobrze i masz uruchomione lokalne wdrożenie Vitess w węźle. Następnym krokiem będzie zaimportowanie naszego klastra wdrożonego przez ClusterControl do Vitess. W tym celu musimy uruchomić jeszcze dwa tablety VTTablet. Najpierw utworzymy katalogi dla tych tabletów 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_0000000402Następnie w bazie danych utworzymy użytkownika, który będzie używany przez Vitess do łączenia się i zarządzania bazą danych.
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)Jeśli chcemy, możemy również utworzyć więcej użytkowników. Vitess pozwala nam przekazać kilku użytkowników o różnych uprawnieniach dostępu:użytkownik aplikacji, użytkownik DBA, użytkownik replikacji, użytkownik w pełni uprzywilejowany i kilku innych.
Ostatnią rzeczą, którą musimy zrobić, to wyłączyć super_read_only we wszystkich MySQL węzły, ponieważ Vitess spróbuje utworzyć metadane w replice, co spowoduje nieudaną próbę uruchomienia usługi vttablet.
Gdy to zrobimy, powinniśmy uruchomić VTTablets. W obu przypadkach musimy upewnić się, że porty są unikalne i że przekazujemy prawidłowe dane uwierzytelniające, aby uzyskać dostęp do instancji bazy danych:
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 &Gdy będzie gotowy, możemy sprawdzić, jak Vitess widzi nowe 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)Węzły są dostępne, ale oba są zgłaszane przez Vitess jako repliki. Możemy teraz wywołać Vitess, aby sprawdził topologię naszego prawdziwego mastera (węzeł, który zaimportowaliśmy z ID 401)
[email protected]:~/my-vitess-example$ vtctlclient TabletExternallyReparented zone1-401Teraz wszystko wygląda poprawnie:
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)Integracja automatycznego przełączania awaryjnego ClusterControl z Vitess
Ostatnim elementem, któremu chcemy się przyjrzeć, jest zautomatyzowana obsługa przełączania awaryjnego za pomocą ClusterControl i zobaczmy, jak można ją zintegrować z Vitess. Będzie bardzo podobny do tego, co właśnie widzieliśmy. Głównym problemem, z którym należy sobie poradzić, jest to, że przełączenie awaryjne nie zmienia niczego w Vitess. Rozwiązaniem jest to, co zastosowaliśmy wcześniej, polecenie TabletExternallyReparented. Jedynym wyzwaniem jest wyzwolenie go, gdy nastąpi przełączenie awaryjne. Na szczęście ClusterControl jest wyposażony w zaczepy, które pozwalają nam podłączyć się do procesu przełączania awaryjnego. Wykorzystamy je do uruchomienia vtctlclient. Należy jednak najpierw zainstalować go na instancji ClusterControl. Najprostszym sposobem na osiągnięcie tego jest po prostu skopiowanie pliku binarnego z instancji Vitess do ClusterControl.
Najpierw utwórzmy katalog w węźle ClusterControl:
mkdir -r /usr/local/vitess/binNastępnie skopiuj plik:
scp /usr/local/vitess/bin/vtctlclient [email protected]:/usr/local/vitess/bin/W następnym kroku musimy stworzyć skrypt, który wykona polecenie ponownego rodzicielstwa shardów. Użyjemy replication_post_failover_script i replication_post_switchover_script. Cmon wykona skrypt z kilkoma argumentami. Interesuje nas trzeci z nich, będzie on zawierał nazwę hosta kandydata na mastera - węzła, który został wybrany jako nowy master.
Przykładowy skrypt może wyglądać mniej więcej tak.
#!/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}Pamiętaj, że jest to tylko absolutne minimum, które działa. Powinieneś zaimplementować bardziej szczegółowy skrypt, który może wykonać dodatkowe testy poprawności. Zamiast zakodować na stałe nazwy hostów i nazwy tabletów, możesz faktycznie zapytać ClusterControl, aby uzyskać listę węzłów w klastrze, możesz porównać ją z zawartością usługi topologii, aby zobaczyć, który alias tabletu powinien zostać użyty.
Gdy jesteśmy gotowi ze skryptem, powinniśmy skonfigurować go tak, aby był wykonywany przez ClusterControl:
Możemy to przetestować, ręcznie promując replikę. Stan początkowy, według Vitess, był następujący:
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)Interesuje nas przestrzeń klawiszy „clustercontrol”. 401 (10.0.0.181) był mistrzem, a 402 (10.0.0.182) był repliką.
Możemy promować 10.0.0.182 na nowego mistrza. Rozpoczyna się praca i widzimy, że nasz skrypt został wykonany:
Wreszcie zadanie zostało zakończone:
Wszystko poszło dobrze w ClusterControl. Rzućmy okiem 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 widać, tutaj również wszystko jest w porządku. 402 to nowy master, a 401 jest oznaczony jako replika.
Oczywiście jest to tylko przykład tego, jak można skorzystać z możliwości ClusterControl do monitorowania i zarządzania bazami danych MySQL, przy jednoczesnym korzystaniu ze zdolności Vitess do skalowania i dzielenia danych. Vitess to świetne narzędzie, ale brakuje w nim kilku elementów. Na szczęście ClusterControl może wykonać kopię zapasową w takich przypadkach.
