ProxySQL es un equilibrador de carga bien conocido en el mundo de MySQL:viene con un gran conjunto de funciones que le permiten controlar su tráfico y darle la forma que mejor le parezca. Se puede implementar de muchas maneras diferentes:nodos dedicados, ubicación conjunta con hosts de aplicaciones, enfoque de silo, todo depende del entorno exacto y los requisitos comerciales. El desafío común es que, en la mayoría de los casos, desea que sus nodos ProxySQL contengan la misma configuración. Si escala su clúster y agrega un nuevo servidor a ProxySQL, querrá que ese servidor esté visible en todas las instancias de ProxySQL, no solo en la activa. Esto lleva a la pregunta:¿cómo asegurarse de mantener la configuración sincronizada en todos los nodos de ProxySQL?
Puede intentar actualizar todos los nodos a mano, lo que definitivamente no es eficiente. También puede usar algún tipo de herramientas de orquestación de infraestructura como Ansible o Chef para mantener la configuración en los nodos en un estado conocido, haciendo las modificaciones no directamente en ProxySQL sino a través de la herramienta que usa para organizar su entorno.
Si usa ClusterControl, viene con un conjunto de características que le permiten sincronizar la configuración entre instancias de ProxySQL, pero esta solución tiene sus contras:es una acción manual, debe recordar ejecutarlo después de un cambio de configuración. Si olvida hacer eso, puede llevarse una desagradable sorpresa si, por ejemplo, keepalived moverá la IP virtual a la instancia de ProxySQL no actualizada.
Ninguno de esos métodos es simple o 100% confiable y la situación es cuando los nodos ProxySQL tienen configuraciones diferentes y pueden ser potencialmente peligrosos.
Afortunadamente, ProxySQL viene con una solución para este problema:ProxySQL Cluster. La idea es bastante simple:puede definir una lista de instancias de ProxySQL que se comunicarán entre sí e informarán a otros sobre la versión de la configuración que contiene cada una de ellas. La configuración está versionada, por lo tanto, cualquier modificación de cualquier configuración en cualquier nodo dará como resultado un aumento de la versión de la configuración; esto activa la sincronización de la configuración y la nueva versión de la configuración se distribuye y aplica en todos los nodos que forman el clúster de ProxySQL.
La versión reciente de ClusterControl le permite configurar clústeres de ProxySQL sin esfuerzo. Al implementar ProxySQL, debe marcar la opción "Usar clústeres nativos" para todos los nodos que desea que formen parte del clúster.
Una vez que haces eso, casi terminas; el resto sucede bajo el capó.
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)En ambos servidores, la tabla proxysql_servers se configuró correctamente con los nombres de host de los nodos que forman el clúster. También podemos verificar que los cambios de configuración se propagan correctamente en el clúster:
Hemos aumentado la configuración Max Connections en uno de los nodos ProxySQL (10.0 .0.131) y podemos comprobar que el otro nodo (10.0.0.132) verá la misma configuración:
En caso de que sea necesario depurar el proceso, siempre podemos buscar el registro de ProxySQL (generalmente ubicado en /var/lib/proxysql/proxysql.log) donde veremos información 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 es el registro de 10.0.0.132 donde podemos ver claramente que se detectó un cambio de configuración para la tabla mysql_servers en 10.0.0.131 y luego se sincronizó y aplicó en 10.0.0.132, por lo que está sincronizado con el otro nodo del clúster.
Como puede ver, agrupar ProxySQL en clústeres es una manera fácil pero eficiente de garantizar que su configuración permanezca sincronizada y ayuda significativamente a usar implementaciones de ProxySQL más grandes. Háganos saber en los comentarios cuál es su experiencia con la agrupación en clústeres de ProxySQL.
