Pour tous ceux qui ne sont pas familiers avec Vitess, il s'agit d'un système de base de données basé sur MySQL qui est destiné à fournir un système de gestion de base de données relationnelle, partagé et facile à mettre à l'échelle. Nous n'entrerons pas dans les détails de la conception mais, en bref, Vitess se compose de nœuds proxy qui acheminent les requêtes, de passerelles qui gèrent les nœuds de la base de données et, enfin, des nœuds de la base de données MySQL eux-mêmes, qui sont destinés à stocker les données. Si nous parlons de MySQL, on peut penser s'il existe une option pour, en fait, utiliser des outils externes comme, par exemple, ClusterControl pour gérer ces bases de données sous-jacentes. La réponse courte est "oui". Une réponse plus longue sera ce billet de blog.
MySQL dans Vitess
Tout d'abord, nous voulons passer un peu de temps à parler de la façon dont Vitess utilise MySQL. L'architecture de haut niveau est décrite sur la page de documentation de Vitess. En bref, nous avons VTGate qui agit comme un proxy, nous avons un service de topologie qui est un magasin de métadonnées basé sur Zookeeper, Consul ou Etcd, où se trouvent toutes les informations sur les nœuds du système, enfin nous avons VTTablets, qui agissent en tant qu'intermédiaire entre VTGate et l'instance MySQL. Les instances MySQL peuvent être autonomes ou configurées à l'aide d'une réplication asynchrone (ou semi-synchrone) standard. MySQL est utilisé pour stocker des données. Les données peuvent être divisées en fragments, dans ce cas une instance MySQL contiendra un sous-ensemble des données.
Tout cela fonctionne très bien. Vitess est capable de déterminer quel nœud est le maître, quels nœuds sont les esclaves, acheminant les requêtes en conséquence. Il y a cependant plusieurs problèmes. Toutes les fonctionnalités les plus élémentaires ne sont pas fournies par Vitess. Détection de la topologie et routage des requêtes, oui. Sauvegardes - oui aussi, Vitess peut être configuré pour effectuer des sauvegardes des données et permettre aux utilisateurs de restaurer tout ce qui a été sauvegardé. Malheureusement, il n'y a pas de support interne pour le basculement automatisé. Il n'y a pas d'interface utilisateur de tendance appropriée qui aiderait les utilisateurs à comprendre l'état des bases de données et leur charge de travail. Heureusement, comme nous parlons de MySQL standard, nous pouvons facilement utiliser des solutions externes pour y parvenir. Par exemple, pour le basculement, Vitess peut être intégré à Orchestrator. Voyons comment ClusterControl peut être utilisé conjointement avec Vitess pour assurer la gestion, la surveillance et le basculement.
Déploiement d'un nouveau cluster de base de données à l'aide de ClusterControl
Tout d'abord, déployons un nouveau cluster. Comme d'habitude avec ClusterControl, vous devez provisionner le matériel et vous assurer que ClusterControl peut accéder à ces nœuds à l'aide de SSH.
Nous devons d'abord définir la connectivité SSH.
Ensuite, nous choisirons le fournisseur et la version. Selon la documentation, Vitess prend en charge MySQL et Percona Server dans les versions 5.7 et 8.0 (bien qu'il ne prenne pas en charge la méthode caching_sha2_password, vous devez donc être prudent lors de la création d'utilisateurs). Il prend également en charge MariaDB jusqu'à 10.3.
Enfin, nous définissons la topologie. Après avoir cliqué sur "Déployer", ClusterControl effectuera le déploiement du cluster.
Une fois qu'il est prêt, vous devriez voir le cluster et vous devriez pouvoir gérez-le à l'aide de ClusterControl. Si la récupération automatique pour le cluster et le nœud est activée, ClusterControl effectuera des basculements automatisés si cela s'avère nécessaire.
Vous bénéficierez également d'une surveillance basée sur des agents dans la section "Tableau de bord" de l'interface utilisateur de ClusterControl.
Importer le cluster dans Vitess
Dans une prochaine étape, nous devrions déployer Vitess. Ce que nous décrivons ici n'est en aucun cas une configuration de niveau production, nous allons donc couper les coins ronds et simplement déployer la suite Vitess sur un seul nœud en suivant le didacticiel de la documentation Vitess. Pour faciliter la gestion, nous utiliserons le guide d'installation locale, qui déploiera tous les services, ainsi que des exemples de bases de données sur un seul nœud. Faites-le assez grand pour les accueillir. À des fins de test, un nœud avec quelques cœurs de processeur et 4 Go de mémoire devrait suffire.
Supposons que tout s'est bien passé et que vous avez un déploiement Vitess local en cours d'exécution sur le nœud. La prochaine étape consistera à importer notre cluster déployé par ClusterControl dans Vitess. Pour cela, nous devons exécuter deux autres VTTablets. Tout d'abord, nous allons créer des répertoires pour ces VTTablets :
[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_0000000402Ensuite, sur la base de données, nous allons créer un utilisateur qui sera utilisé par Vitess pour se connecter et gérer la base de données.
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)Si nous le voulons, nous pouvons également créer plus d'utilisateurs. Vitess nous permet de passer quelques utilisateurs avec différents privilèges d'accès :utilisateur de l'application, utilisateur DBA, utilisateur de réplication, utilisateur entièrement privilégié et quelques autres.
La dernière chose que nous devons faire est de désactiver le super_read_only sur tous les MySQL nœuds car Vitess tentera de créer des métadonnées sur le réplica, ce qui entraînera une tentative infructueuse de démarrage du service vttablet.
Une fois cela fait, nous devrions démarrer VTTablets. Dans les deux cas, nous devons nous assurer que les ports sont uniques et que nous transmettons les informations d'identification correctes pour accéder à l'instance de base de données :
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 &Une fois qu'il est prêt, nous pouvons vérifier comment Vitess voit les nouveaux VTTablets :
[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)Les nœuds sont là mais les deux sont signalés comme des répliques par Vitess. Nous pouvons maintenant déclencher Vitess pour vérifier la topologie de notre véritable maître (nœud que nous avons importé avec l'ID 401)
[email protected]:~/my-vitess-example$ vtctlclient TabletExternallyReparented zone1-401Maintenant, tout semble correct :
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)Intégration du basculement automatisé ClusterControl dans Vitess
La dernière partie que nous voulons examiner est la gestion automatisée du basculement avec ClusterControl et voir comment vous pouvez l'intégrer à Vitess. Ce sera assez semblable à ce que nous venons de voir. Le principal problème à traiter est que le basculement ne change rien au Vitess. La solution est ce que nous avons utilisé précédemment, la commande TabletExternallyReparented. Le seul défi est de le déclencher lorsque le basculement se produit. Heureusement, ClusterControl est livré avec des crochets qui nous permettent de nous connecter au processus de basculement. Nous les utiliserons pour exécuter le vtctlclient. Cependant, il doit d'abord être installé sur l'instance ClusterControl. Le moyen le plus simple d'y parvenir consiste simplement à copier le binaire de l'instance Vitess vers ClusterControl.
Commençons par créer le répertoire sur le nœud ClusterControl :
mkdir -r /usr/local/vitess/binEnsuite, copiez simplement le fichier :
scp /usr/local/vitess/bin/vtctlclient [email protected]:/usr/local/vitess/bin/Dans une prochaine étape, nous devons créer un script qui exécutera la commande pour reparent les fragments. Nous utiliserons replication_post_failover_script et replication_post_switchover_script. Cmon exécutera le script avec plusieurs arguments. Nous nous intéressons au troisième d'entre eux, il contiendra le nom d'hôte du candidat maître - le nœud qui a été choisi comme nouveau maître.
L'exemple de script peut ressembler à ceci.
#!/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}S'il vous plaît gardez à l'esprit que ce n'est qu'un strict minimum qui fonctionne. Vous devez implémenter un script plus détaillé qui effectuera peut-être des vérifications supplémentaires. Au lieu de coder en dur les noms d'hôte et les noms de tablette, vous pouvez en fait interroger ClusterControl pour obtenir la liste des nœuds du cluster, puis vous pouvez la comparer avec le contenu du service de topologie pour voir quel alias de tablette doit être utilisé.
Une fois que nous sommes prêts avec le script, nous devons le configurer pour qu'il soit exécuté par ClusterControl :
Nous pouvons tester cela en promouvant manuellement le réplica. L'état initial, tel que vu par Vitess, était :
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)Nous sommes intéressés par l'espace de clés "clustercontrol". 401 (10.0.0.181) était le maître et 402 (10.0.0.182) était la réplique.
Nous pouvons promouvoir 10.0.0.182 pour devenir un nouveau maître. Le travail démarre et nous pouvons voir que notre script a été exécuté :
Enfin, le travail est terminé :
Tout s'est bien passé dans le ClusterControl. Jetons un coup d'œil à 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)Comme vous pouvez le voir, tout va bien ici aussi. 402 est le nouveau maître et 401 est marqué comme réplique.
Bien sûr, ceci n'est qu'un exemple de la façon dont vous pouvez bénéficier de la capacité de ClusterControl à surveiller et gérer vos bases de données MySQL tout en continuant à tirer parti de la capacité de Vitess à faire évoluer et à partager les données. Vitess est un excellent outil mais il lui manque quelques éléments. Heureusement, ClusterControl peut vous aider dans ces cas.
