Para todos los que no están familiarizados con Vitess, es un sistema de base de datos basado en MySQL que está diseñado para ofrecer un sistema de administración de base de datos relacional fragmentado y fácil de escalar. No entraremos en detalles sobre el diseño pero, en resumen, Vitess consta de nodos proxy que enrutan las solicitudes, puertas de enlace que administran los nodos de la base de datos y, finalmente, los propios nodos de la base de datos MySQL, que están destinados a almacenar los datos. Si estamos hablando de MySQL, uno puede pensar si existe una opción para, de hecho, usar herramientas externas como, por ejemplo, ClusterControl para administrar esas bases de datos subyacentes. La respuesta corta es "sí". La respuesta más larga será esta entrada de blog.
MySQL en Vitess
En primer lugar, queremos dedicar un poco de tiempo a hablar sobre cómo Vitess usa MySQL. La arquitectura de alto nivel se describe en la página de documentación de Vitess. En definitiva, tenemos VTGate que actúa como proxy, tenemos un Servicio de Topología que es un almacén de metadatos basado en Zookeeper, Consul o Etcd, donde se encuentra toda la información de los nodos del sistema, finalmente tenemos VTTtablets, que actúan como intermediario entre VTGate y la instancia de MySQL. Las instancias de MySQL pueden ser independientes o pueden configurarse mediante replicación asincrónica (o semisíncrona) estándar. MySQL se utiliza para almacenar datos. Los datos se pueden dividir en fragmentos, en ese caso, una instancia de MySQL contendrá un subconjunto de los datos.
Todo esto funciona muy bien. Vitess puede determinar qué nodo es el maestro, qué nodos son los esclavos y enruta las consultas en consecuencia. Sin embargo, hay varios problemas. Vitess no ofrece todas las funciones más básicas. Detección de topología y enrutamiento de consultas, sí. Copias de seguridad:sí, Vitess también se puede configurar para realizar copias de seguridad de los datos y permitir que los usuarios restauren lo que se haya respaldado. Desafortunadamente, no hay soporte interno para la conmutación por error automatizada. No existe una interfaz de usuario de tendencias adecuada que ayude a los usuarios a comprender el estado de las bases de datos y su carga de trabajo. Afortunadamente, como estamos hablando de MySQL estándar, podemos usar fácilmente soluciones externas para lograr esto. Por ejemplo, para la conmutación por error, Vitess se puede integrar con Orchestrator. Echemos un vistazo a cómo se puede usar ClusterControl junto con Vitess para proporcionar administración, monitoreo y conmutación por error.
Implementación de un nuevo clúster de base de datos mediante ClusterControl
Primero, implementemos un nuevo clúster. Como es habitual con ClusterControl, debe aprovisionar el hardware y asegurarse de que ClusterControl pueda acceder a esos nodos mediante SSH.
Primero, tenemos que definir la conectividad SSH.
A continuación, elegiremos el proveedor y la versión. Según la documentación, Vitess admite MySQL y Percona Server en las versiones 5.7 y 8.0 (aunque no admite el método caching_sha2_password, por lo que debe tener cuidado al crear usuarios). También es compatible con MariaDB hasta 10.3.
Finalmente, definimos la topología. Después de hacer clic en "Implementar", ClusterControl realizará la implementación del clúster.
Una vez que esté listo, debería ver el clúster y debería poder administrarlo usando ClusterControl. Si la Recuperación automática para el clúster y el nodo están habilitadas, ClusterControl realizará conmutaciones por error automáticas en caso de que sea necesario.
También se beneficiará de la supervisión basada en agentes en la sección "Panel" de la interfaz de usuario de ClusterControl.
Importación del clúster a Vitess
Como siguiente paso, deberíamos implementar Vitess. Lo que describimos aquí no es de ninguna manera una configuración de nivel de producción, por lo tanto, vamos a reducir algunos gastos e implementar Vitess Suite en un solo nodo siguiendo el tutorial de la documentación de Vitess. Para que sea más fácil de manejar, utilizaremos la guía de instalación local, que implementará todos los servicios, junto con bases de datos de ejemplo en un solo nodo. Hágalo lo suficientemente grande para acomodarlos. Para fines de prueba, un nodo con un par de núcleos de CPU y 4 GB de memoria debería ser suficiente.
Supongamos que todo salió bien y tiene una implementación local de Vitess ejecutándose en el nodo. El siguiente paso será importar nuestro clúster implementado por ClusterControl en Vitess. Para eso tenemos que ejecutar dos VTVTablets más. Primero, crearemos directorios para esos VTTtablets:
[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_0000000402Luego, en la base de datos, vamos a crear un usuario que se usará para que Vitess se conecte y administre la base de datos.
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 queremos, también podemos querer crear más usuarios. Vitess nos permite pasar un par de usuarios con diferentes privilegios de acceso:usuario de la aplicación, usuario DBA, usuario de replicación, usuario con todos los privilegios y un par más.
Lo último que tenemos que hacer es desactivar super_read_only en todos los MySQL nodos como Vitess intentarán crear metadatos en la réplica, lo que resultará en un intento fallido de iniciar el servicio vttablet.
Una vez hecho esto, debemos iniciar VTTablets. En ambos casos, debemos asegurarnos de que los puertos sean únicos y de que pasemos las credenciales correctas para acceder a la instancia de la base de datos:
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 &Una vez que esté listo, podemos comprobar cómo ve Vitess las nuevas VTVTablets:
[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)Los nodos están ahí, pero Vitess informa que ambos son réplicas. Ahora podemos activar Vitess para verificar la topología de nuestro maestro real (nodo que importamos con ID de 401)
[email protected]:~/my-vitess-example$ vtctlclient TabletExternallyReparented zone1-401Ahora todo parece correcto:
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)Integración de la conmutación por error automatizada de ClusterControl en Vitess
Lo último que queremos ver es el manejo automatizado de conmutación por error con ClusterControl y ver cómo puede integrarlo con Vitess. Será bastante similar a lo que acabamos de ver. El principal problema con el que hay que lidiar es que la conmutación por error no cambia nada en el Vitess. La solución es lo que hemos usado anteriormente, el comando TabletExternallyReparented. El único desafío es activarlo cuando ocurre la conmutación por error. Afortunadamente, ClusterControl viene con ganchos que nos permiten conectarnos al proceso de conmutación por error. Los usaremos para ejecutar vtctlclient. Sin embargo, primero debe instalarse en la instancia de ClusterControl. La forma más fácil de lograrlo es simplemente copiando el binario de la instancia de Vitess a ClusterControl.
Primero, creemos el directorio en el nodo ClusterControl:
mkdir -r /usr/local/vitess/binLuego, simplemente copie el archivo:
scp /usr/local/vitess/bin/vtctlclient [email protected]:/usr/local/vitess/bin/Como siguiente paso, tenemos que crear un script que ejecutará el comando para volver a generar fragmentos. Usaremos replication_post_failover_script y replication_post_switchover_script. Cmon ejecutará el script con varios argumentos. Estamos interesados en el tercero de ellos, contendrá el nombre de host del candidato a maestro:el nodo que se eligió como nuevo maestro.
La secuencia de comandos de ejemplo puede verse así.
#!/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}Por favor, tenga en cuenta que esto es solo un mínimo que funciona. Debe implementar una secuencia de comandos más detallada que realice quizás controles de cordura adicionales. En lugar de codificar los nombres de host y tabletas, puede consultar ClusterControl para obtener la lista de nodos en el clúster, luego puede compararlo con el contenido del Servicio de topología para ver qué alias de tableta se debe usar.
Una vez que estemos listos con el script, debemos configurarlo para que lo ejecute ClusterControl:
Podemos probar esto promocionando manualmente la réplica. El estado inicial, visto por Vitess, era:
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)Estamos interesados en el espacio de claves 'clustercontrol'. 401 (10.0.0.181) era el maestro y 402 (10.0.0.182) era la réplica.
Podemos promover 10.0.0.182 para convertirse en un nuevo maestro. El trabajo comienza y podemos ver que nuestro script se ejecutó:
Finalmente, el trabajo está completo:
Todo salió bien en el ClusterControl. Echemos un vistazo a 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)Como puede ver, todo está bien aquí también. 402 es el nuevo maestro y 401 está marcado como la réplica.
Por supuesto, este es solo un ejemplo de cómo puede beneficiarse de la capacidad de ClusterControl para monitorear y administrar sus bases de datos MySQL mientras aún puede aprovechar la capacidad de Vitess para escalar y fragmentar los datos. Vitess es una gran herramienta pero le faltan un par de elementos. Afortunadamente, ClusterControl puede respaldarlo en esos casos.
