Para todos que não estão familiarizados com o Vitess, é um sistema de banco de dados baseado em MySQL que se destina a fornecer um sistema de gerenciamento de banco de dados relacional, fragmentado e fácil de dimensionar. Não entraremos em detalhes sobre o design, mas, em resumo, o Vitess consiste em nós proxy que roteiam as solicitações, gateways que gerenciam os nós do banco de dados e, finalmente, os próprios nós do banco de dados MySQL, que se destinam a armazenar os dados. Se estamos falando do MySQL, pode-se pensar se existe a opção de, na verdade, usar ferramentas externas como, por exemplo, ClusterControl para gerenciar esses bancos de dados subjacentes. A resposta curta é “sim”. A resposta mais longa será esta postagem no blog.
MySQL no Vitess
Primeiro de tudo, queremos gastar um pouco de tempo falando sobre como o Vitess usa o MySQL. A arquitetura de alto nível é descrita na página de documentação do Vitess. Resumindo, temos o VTGate que atua como proxy, temos um Serviço de Topologia que é um repositório de metadados baseado em Zookeeper, Consul ou Etcd, onde estão localizadas todas as informações sobre os nós do sistema, por fim temos os VTTablets, que atuam como intermediário entre a instância VTGate e MySQL. As instâncias do MySQL podem ser independentes ou podem ser configuradas usando replicação assíncrona padrão (ou semi-síncrona). MySQL é usado para armazenar dados. Os dados podem ser divididos em fragmentos; nesse caso, uma instância do MySQL conterá um subconjunto dos dados.
Tudo isso funciona muito bem. Vitess é capaz de determinar qual nó é o mestre, quais nós são escravos, roteando as consultas de acordo. Existem vários problemas, no entanto. Nem todas as funcionalidades mais básicas são fornecidas pela Vitess. Detecção de topologia e roteamento de consultas, sim. Backups - sim também, o Vitess pode ser configurado para fazer backups dos dados e permitir que os usuários restaurem o que foi copiado. Infelizmente, não há suporte interno para failover automatizado. Não há uma interface de usuário de tendências adequada que ajude os usuários a entender o estado dos bancos de dados e sua carga de trabalho. Felizmente, como estamos falando do MySQL padrão, podemos facilmente usar soluções externas para fazer isso. Por exemplo, para failover, o Vitess pode ser integrado ao Orchestrator. Vamos dar uma olhada em como o ClusterControl pode ser usado em conjunto com o Vitess para fornecer gerenciamento, monitoramento e failover.
Implantando um novo cluster de banco de dados usando ClusterControl
Primeiro, vamos implantar um novo cluster. Como de costume com o ClusterControl, você precisa provisionar hardware e garantir que o ClusterControl possa acessar esses nós usando SSH.
Primeiro, temos que definir a conectividade SSH.
A seguir, escolheremos o fornecedor e a versão. De acordo com a documentação, o Vitess suporta MySQL e Percona Server nas versões 5.7 e 8.0 (embora não suporte o método caching_sha2_password, então você deve ter cuidado ao criar usuários). Ele também suporta MariaDB até 10.3.
Finalmente, definimos a topologia. Após clicar em “Deploy”, o ClusterControl realizará a implantação do cluster.
Quando estiver pronto, você deverá ver o cluster e poderá gerenciá-lo usando ClusterControl. Se a Recuperação Automática para Cluster e Nó estiver habilitada, o ClusterControl executará failovers automatizados caso seja necessário.
Você também se beneficiará do monitoramento baseado em agente na seção "Painel" da interface do usuário do ClusterControl.
Importando o cluster para o Vitess
Como próximo passo, devemos implantar o Vitess. O que descrevemos aqui não é de forma alguma uma configuração de nível de produção, portanto, vamos cortar alguns cantos e apenas implantar o pacote Vitess em um único nó seguindo o tutorial da documentação do Vitess. Para facilitar o manuseio, usaremos o guia Local Install, que implantará todos os serviços, juntamente com bancos de dados de exemplo em um único nó. Torná-lo grande o suficiente para acomodá-los. Para fins de teste, um nó com alguns núcleos de CPU e 4 GB de memória deve ser suficiente.
Vamos supor que tudo correu bem e você tem uma implantação local do Vitess em execução no nó. O próximo passo será importar nosso cluster implantado pelo ClusterControl para o Vitess. Para isso temos que rodar mais dois VTTablets. Primeiro, vamos criar diretórios para esses 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_0000000402Então, no banco de dados, vamos criar um usuário que será usado pelo Vitess para conectar e gerenciar o banco de dados.
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)Se quisermos, também podemos criar mais usuários. O Vitess nos permite passar alguns usuários com diferentes privilégios de acesso:usuário do aplicativo, usuário DBA, usuário de replicação, usuário totalmente privilegiado e mais alguns.
A última coisa que precisamos fazer é desabilitar o super_read_only em todos os MySQL nós, pois o Vitess tentará criar metadados na réplica, resultando em uma tentativa fracassada de iniciar o serviço vttablet.
Uma vez feito isso, devemos iniciar o VTTablets. Em ambos os casos, temos que garantir que as portas sejam únicas e que passemos as credenciais corretas para acessar a instância do banco de dados:
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 &Depois de pronto, podemos verificar como o Vitess vê os novos 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)Os nós existem, mas ambos são relatados como réplicas pelo Vitess. Agora podemos acionar o Vitess para verificar a topologia do nosso mestre real (nó que importamos com ID de 401)
[email protected]:~/my-vitess-example$ vtctlclient TabletExternallyReparented zone1-401Agora tudo parece correto:
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)Integrando o failover automatizado do ClusterControl no Vitess
A última parte que queremos examinar é o tratamento automatizado de failover com o ClusterControl e ver como você pode integrá-lo ao Vitess. Será bastante semelhante ao que acabamos de ver. O principal problema a ser tratado é que o failover não altera nada no Vitess. A solução é o que usamos anteriormente, o comando TabletExternallyReparented. O único desafio é acioná-lo quando o failover ocorrer. Felizmente, o ClusterControl vem com ganchos que nos permitem conectar ao processo de failover. Vamos usá-los para executar o vtctlclient. No entanto, ele deve ser instalado na instância ClusterControl primeiro. A maneira mais fácil de fazer isso é apenas copiando o binário da instância Vitess para o ClusterControl.
Primeiro, vamos criar o diretório no nó ClusterControl:
mkdir -r /usr/local/vitess/binDepois, basta copiar o arquivo:
scp /usr/local/vitess/bin/vtctlclient [email protected]:/usr/local/vitess/bin/Como próximo passo, temos que criar um script que executará o comando para reparentar shards. Usaremos replication_post_failover_script e replication_post_switchover_script. Cmon executará o script com vários argumentos. Estamos interessados no terceiro deles, ele conterá o nome do host do candidato a mestre - o nó que foi escolhido como um novo mestre.
O script de exemplo pode ser algo assim.
#!/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, tenha em mente que este é apenas o mínimo que funciona. Você deve implementar um script mais detalhado que possa realizar verificações de sanidade adicionais. Em vez de codificar os nomes de host e de tablet, você pode consultar o ClusterControl para obter a lista de nós no cluster e, em seguida, compará-lo com o conteúdo do Serviço de Topologia para ver qual alias de tablet deve ser usado.
Assim que estivermos prontos com o script, devemos configurá-lo para ser executado pelo ClusterControl:
Podemos testar isso promovendo manualmente a réplica. O estado inicial, como visto por Vitess, foi:
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 interessados no keyspace 'clustercontrol'. 401 (10.0.0.181) era o mestre e 402 (10.0.0.182) era a réplica.
Podemos promover 10.0.0.182 para se tornar um novo mestre. O trabalho é iniciado e podemos ver que nosso script foi executado:
Finalmente, o trabalho foi concluído:
Tudo correu bem no ClusterControl. Vamos dar uma olhada em 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 você pode ver, tudo está bem aqui também. 402 é o novo mestre e 401 é marcado como a réplica.
Claro, este é apenas um exemplo de como você pode se beneficiar da capacidade do ClusterControl de monitorar e gerenciar seus bancos de dados MySQL enquanto ainda é capaz de aproveitar a capacidade do Vitess de dimensionar e fragmentar os dados. Vitess é uma ótima ferramenta, mas faltam alguns elementos. Felizmente, o ClusterControl pode fazer backup nesses casos.
