ProxySQL é um balanceador de carga bem conhecido no mundo MySQL - ele vem com um grande conjunto de recursos que permitem que você assuma o controle sobre seu tráfego e o modele da maneira que achar melhor. Ele pode ser implantado de muitas maneiras diferentes - nós dedicados, colocados com hosts de aplicativos, abordagem de silo - tudo depende do ambiente exato e dos requisitos de negócios. O desafio comum é que você, na maioria dos casos, deseja que seus nós ProxySQL contenham a mesma configuração. Se você expandir seu cluster e adicionar um novo servidor ao ProxySQL, desejará que esse servidor fique visível em todas as instâncias do ProxySQL, não apenas na ativa. Isso leva à pergunta - como garantir que você mantenha a configuração sincronizada em todos os nós ProxySQL?
Você pode tentar atualizar todos os nós manualmente, o que definitivamente não é eficiente. Você também pode usar algum tipo de ferramenta de orquestração de infraestrutura como Ansible ou Chef para manter a configuração nos nós em um estado conhecido, fazendo as modificações não diretamente no ProxySQL, mas por meio da ferramenta que você usa para organizar seu ambiente.
Se você usar o ClusterControl, ele vem com um conjunto de recursos que permitem sincronizar a configuração entre instâncias do ProxySQL, mas esta solução tem seus contras - é uma ação manual, você deve se lembrar de executá-lo após uma alteração de configuração. Se você esquecer de fazer isso, poderá ter uma surpresa desagradável se, por exemplo, keepalived mover o IP virtual para a instância ProxySQL não atualizada.
Nenhum desses métodos é simples ou 100% confiável e a situação é quando os nós ProxySQL têm configurações diferentes e podem ser potencialmente perigosos.
Felizmente, o ProxySQL vem com uma solução para este problema - ProxySQL Cluster. A ideia é bastante simples - você pode definir uma lista de instâncias do ProxySQL que irão conversar entre si e informar aos outros sobre a versão da configuração que cada uma delas contém. A configuração é versionada, portanto, qualquer modificação de qualquer configuração em qualquer nó resultará no aumento da versão da configuração - isso aciona a sincronização da configuração e a nova versão da configuração é distribuída e aplicada em todos os nós que formam o cluster ProxySQL.
A versão recente do ClusterControl permite que você configure clusters ProxySQL sem esforço. Ao implantar o ProxySQL, você deve marcar a opção “Usar cluster nativo” para todos os nós que deseja que façam parte do cluster.
Depois de fazer isso, você está praticamente pronto - o resto acontece em o capuz.
MySQL [(none)]> select * from proxysql_servers;
+------------+------+--------+----------------+
| hostname | port | weight | comment |
+------------+------+--------+----------------+
| 10.0.0.131 | 6032 | 0 | proxysql_group |
| 10.0.0.132 | 6032 | 0 | proxysql_group |
+------------+------+--------+----------------+
2 rows in set (0.001 sec)Em ambos os servidores a tabela proxysql_servers foi configurada corretamente com os nomes de host dos nós que formam o cluster. Também podemos verificar se as alterações de configuração são propagadas corretamente no cluster:
Aumentamos a configuração Max Connections em um dos nós ProxySQL (10.0 .0.131) e podemos verificar se o outro nó (10.0.0.132) verá a mesma configuração:
Em caso de necessidade de depurar o processo, podemos sempre procurar o log do ProxySQL (normalmente localizado em /var/lib/proxysql/proxysql.log) onde veremos informações como esta:
2020-11-26 13:40:47 [INFO] Cluster: detected a new checksum for mysql_servers from peer 10.0.0.131:6032, version 11, epoch 1606398059, checksum 0x441378E48BB01C61 . Not syncing yet ...
2020-11-26 13:40:49 [INFO] Cluster: detected a peer 10.0.0.131:6032 with mysql_servers version 12, epoch 1606398060, diff_check 3. Own version: 9, epoch: 1606398022. Proceeding with remote sync
2020-11-26 13:40:50 [INFO] Cluster: detected a peer 10.0.0.131:6032 with mysql_servers version 12, epoch 1606398060, diff_check 4. Own version: 9, epoch: 1606398022. Proceeding with remote sync
2020-11-26 13:40:50 [INFO] Cluster: detected peer 10.0.0.131:6032 with mysql_servers version 12, epoch 1606398060
2020-11-26 13:40:50 [INFO] Cluster: Fetching MySQL Servers from peer 10.0.0.131:6032 started. Expected checksum 0x441378E48BB01C61
2020-11-26 13:40:50 [INFO] Cluster: Fetching MySQL Servers from peer 10.0.0.131:6032 completed
2020-11-26 13:40:50 [INFO] Cluster: Fetching checksum for MySQL Servers from peer 10.0.0.131:6032 before proceessing
2020-11-26 13:40:50 [INFO] Cluster: Fetching checksum for MySQL Servers from peer 10.0.0.131:6032 successful. Checksum: 0x441378E48BB01C61
2020-11-26 13:40:50 [INFO] Cluster: Writing mysql_servers table
2020-11-26 13:40:50 [INFO] Cluster: Writing mysql_replication_hostgroups table
2020-11-26 13:40:50 [INFO] Cluster: Loading to runtime MySQL Servers from peer 10.0.0.131:6032Este é o log de 10.0.0.132 onde podemos ver claramente que uma alteração de configuração para a tabela mysql_servers foi detectada em 10.0.0.131 e depois foi sincronizada e aplicada em 10.0.0.132, tornando-a sincronizada com o outro nó no cluster.
Como você pode ver, agrupar ProxySQL é uma maneira fácil e eficiente de garantir que sua configuração permaneça sincronizada e ajuda significativamente a usar implantações maiores de ProxySQL. Deixe-nos saber nos comentários qual é sua experiência com clustering ProxySQL.
