За всички, които не са запознати с Vitess, това е базирана на MySQL система за бази данни, която е предназначена да предостави лесна за мащабиране, разчленена, релационна система за управление на база данни. Няма да навлизаме в подробности за дизайна, но накратко Vitess се състои от прокси възли, които насочват заявките, шлюзове, които управляват възлите на базата данни и накрая, самите възли на базата данни MySQL, които са предназначени да съхраняват данните. Ако говорим за MySQL, човек може да си помисли дали има опция всъщност да се използват външни инструменти като например ClusterControl за управление на тези основни бази данни. Краткият отговор е „да“. По-дълъг отговор ще бъде тази публикация в блога.
MySQL във Vitess
На първо място, искаме да отделим малко време в разговори за това как Vitess използва MySQL. Архитектурата на високо ниво е описана на страницата с документация на Vitess. Накратко, имаме VTGate, който действа като прокси, имаме топологична услуга, която е хранилище на метаданни, базирано на Zookeeper, Consul или Etcd, където се намира цялата информация за възлите в системата, накрая имаме VTTtablets, които действат като посредник между VTGate и MySQL екземпляр. Инстанциите на MySQL могат да бъдат самостоятелни или могат да бъдат конфигурирани с помощта на стандартна асинхронна (или полусинхронна) репликация. MySQL се използва за съхранение на данни. Данните могат да бъдат разделени на части, в този случай MySQL екземпляр ще съдържа подмножество от данни.
Всичко това работи чудесно. Vitess може да определи кой възел е главен, кои възли са подчинени, като съответно насочва заявките. Има обаче няколко проблема. Не всички от най-основните функции се предоставят от Vitess. Откриване на топология и маршрутизиране на заявки, да. Архивиране - да, Vitess може да бъде конфигуриран да прави архиви на данните и да позволява на потребителите да възстановяват всичко, което е архивирано. За съжаление няма вътрешна поддръжка за автоматично преминаване при отказ. Няма подходящ потребителски интерфейс с тенденция, който да помогне на потребителите да разберат състоянието на базите данни и тяхното работно натоварване. За щастие, тъй като говорим за стандартен MySQL, можем лесно да използваме външни решения, за да постигнем това. Например, за отказване, Vitess може да бъде интегриран с Orchestrator. Нека да разгледаме как ClusterControl може да се използва във връзка с Vitess за осигуряване на управление, наблюдение и превключване при отказ.
Разгръщане на нов клъстер от база данни с помощта на ClusterControl
Първо, нека разположим нов клъстер. Както обикновено с ClusterControl, трябва да осигурите хардуер и да гарантирате, че ClusterControl има достъп до тези възли чрез SSH.
Първо трябва да дефинираме SSH свързаност.
След това ще изберем доставчика и версията. Според документацията Vitess поддържа MySQL и Percona Server във версии 5.7 и 8.0 (въпреки че не поддържа метода caching_sha2_password, така че трябва да внимавате при създаване на потребители). Той също така поддържа MariaDB до 10.3.
Накрая дефинираме топологията. След като щракнете върху „Разгръщане“, ClusterControl ще извърши разгръщането на клъстера.
След като е готов, трябва да видите клъстера и трябва да можете да управлявайте го с помощта на ClusterControl. Ако автоматичното възстановяване за клъстер и възел е активирано, ClusterControl ще извърши автоматизирани откази, ако това е необходимо.
Ще се възползвате и от мониторинг, базиран на агенти в секцията „Табло за управление“ на потребителския интерфейс на ClusterControl.
Импортиране на клъстера във Vitess
Като следваща стъпка трябва да разположим Vitess. Това, което описваме тук, в никакъв случай не е настройка от производствен клас, така че ще отрежем някои ъгли и просто ще разположим Vitess пакет на един възел, следвайки урока от документацията на Vitess. За да улесним справянето с него, ще отидем с ръководството за локална инсталация, което ще разгърне всички услуги, заедно с примерни бази данни на един възел. Направете го достатъчно голям, за да ги побере. За целите на тестването трябва да е достатъчен възел с няколко процесорни ядра и 4GB памет.
Да предположим, че всичко е минало добре и имате локално внедряване на Vitess, работещо на възела. Следващата стъпка ще бъде да импортираме нашия клъстер, разгърнат от ClusterControl, във Vitess. За това трябва да стартираме още два VTT таблета. Първо, ще създадем директории за тези 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_0000000402След това в базата данни ще създадем потребител, който ще се използва за Vitess за свързване и управление на базата данни.
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)Ако искаме, може да искаме да създадем още потребители. Vitess ни позволява да предаваме няколко потребители с различни привилегии за достъп:потребител на приложение, потребител на DBA, потребител на репликация, напълно привилегирован потребител и още няколко.
Последното нещо, което трябва да направим, е да деактивираме super_read_only на всички MySQL възли, тъй като Vitess ще се опита да създаде метаданни върху репликата, което ще доведе до неуспешен опит за стартиране на услугата vttablet.
След като това стане, трябва да стартираме VTTtablets. И в двата случая трябва да се уверим, че портовете са уникални и че предаваме правилни идентификационни данни за достъп до екземпляра на базата данни:
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 &След като е готов, можем да проверим как Vitess вижда новите 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)Възлите има, но и двата са отчетени като реплики от Vitess. Вече можем да задействаме Vitess, за да провери топологията за нашия истински господар (възел, който импортирахме с идентификатор 401)
[email protected]:~/my-vitess-example$ vtctlclient TabletExternallyReparented zone1-401Сега всичко изглежда правилно:
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)Интегриране на ClusterControl автоматично превключване при отказ във Vitess
Последното, което искаме да разгледаме, е автоматизираната обработка на отказ с ClusterControl и да видим как можете да го интегрирате с Vitess. Ще бъде доста подобно на това, което току-що видяхме. Основният проблем, с който трябва да се справите, е, че отказът не променя нищо във Vitess. Решението е това, което използвахме по-рано, командата TabletExternallyReparented. Единственото предизвикателство е да го задействате, когато се случи отказът. За щастие ClusterControl идва с кукички, които ни позволяват да се включим в процеса на отказ. Ще ги използваме за стартиране на vtctlclient. Но първо трябва да се инсталира на екземпляра на ClusterControl. Най-лесният начин да постигнете това е просто като копирате двоичния файл от екземпляр на Vitess в ClusterControl.
Първо, нека създадем директорията на възела ClusterControl:
mkdir -r /usr/local/vitess/binСлед това просто копирайте файла:
scp /usr/local/vitess/bin/vtctlclient [email protected]:/usr/local/vitess/bin/Като следваща стъпка трябва да създадем скрипт, който ще изпълни командата за повторно извличане на фрагменти. Ще използваме replication_post_failover_script и replication_post_switchover_script. Cmon ще изпълни скрипта с няколко аргумента. Интересуваме се от третия от тях, той ще съдържа името на хоста на главния кандидат - възела, който е избран като нов главен.
Примерният скрипт може да изглежда така.
#!/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}Моля, имайте предвид, че това е просто минимум, който работи. Трябва да приложите по-подробен скрипт, който ще извърши може би допълнителни проверки за здравина. Вместо твърдо кодиране на имената на хостове и таблети, можете действително да потърсите ClusterControl, за да получите списъка с възли в клъстера, тогава може да искате да го сравните със съдържанието на Topology Service, за да видите кой псевдоним на таблета трябва да се използва.
След като сме готови със скрипта, трябва да го конфигурираме да се изпълнява от ClusterControl:
Можем да тестваме това, като ръчно популяризираме репликата. Първоначалното състояние, както се вижда от Vitess, беше:
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)Интересуваме се от ключовото пространство „clustercontrol“. 401 (10.0.0.181) беше главният, а 402 (10.0.0.182) беше репликата.
Можем да популяризираме 10.0.0.182, за да станем нов главен. Работата започва и можем да видим, че нашият скрипт е изпълнен:
Най-накрая работата е завършена:
Всичко мина добре в ClusterControl. Нека да разгледаме 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)Както виждате, и тук всичко е наред. 402 е новият главен код, а 401 е маркиран като реплика.
Разбира се, това е само пример за това как можете да се възползвате от способността на ClusterControl да наблюдава и управлява вашите MySQL бази данни, като същевременно можете да използвате способността на Vitess за мащабиране и разделяне на данните. Vitess е страхотен инструмент, но му липсват няколко елемента. За щастие ClusterControl може да ви подкрепи в тези случаи.
