ProxySQL est un équilibreur de charge bien connu dans le monde MySQL - il est livré avec un ensemble de fonctionnalités qui vous permettent de prendre le contrôle de votre trafic et de le façonner comme bon vous semble. Il peut être déployé de différentes manières - nœuds dédiés, colocalisés avec des hôtes d'application, approche en silo - tout dépend de l'environnement exact et des exigences de l'entreprise. Le défi commun est que, dans la plupart des cas, vous souhaitez que vos nœuds ProxySQL contiennent la même configuration. Si vous faites évoluer votre cluster et ajoutez un nouveau serveur à ProxySQL, vous voulez que ce serveur soit visible sur toutes les instances ProxySQL, pas seulement sur celle qui est active. Cela nous amène à la question :comment vous assurer que la configuration reste synchronisée sur tous les nœuds ProxySQL ?
Vous pouvez essayer de mettre à jour tous les nœuds à la main, ce qui n'est certainement pas efficace. Vous pouvez également utiliser une sorte d'outils d'orchestration d'infrastructure comme Ansible ou Chef pour conserver la configuration sur les nœuds dans un état connu, en apportant les modifications non pas directement sur ProxySQL, mais via l'outil que vous utilisez pour organiser votre environnement.
Si vous utilisez ClusterControl, il est livré avec un ensemble de fonctionnalités qui vous permettent de synchroniser la configuration entre les instances ProxySQL mais cette solution a ses inconvénients - c'est une action manuelle, vous devez vous rappeler de l'exécuter après un changement de configuration. Si vous oubliez de le faire, vous pourriez avoir une mauvaise surprise si, par exemple, keepalived déplacera l'adresse IP virtuelle vers l'instance ProxySQL non mise à jour.
Aucune de ces méthodes n'est simple ou fiable à 100 % et la situation est lorsque les nœuds ProxySQL ont des configurations différentes et peuvent être potentiellement dangereux.
Heureusement, ProxySQL propose une solution à ce problème :ProxySQL Cluster. L'idée est assez simple - vous pouvez définir une liste d'instances ProxySQL qui se parleront et informeront les autres de la version de la configuration que chacune d'elles contient. La configuration est versionnée, donc toute modification de n'importe quel paramètre sur n'importe quel nœud entraînera l'augmentation de la version de configuration - cela déclenche la synchronisation de la configuration et la nouvelle version de la configuration est distribuée et appliquée sur tous les nœuds qui forment le cluster ProxySQL.
La version récente de ClusterControl vous permet de configurer des clusters ProxySQL sans effort. Lors du déploiement de ProxySQL, vous devez cocher l'option "Utiliser le clustering natif" pour tous les nœuds que vous souhaitez intégrer au cluster.
Une fois que vous faites cela, vous avez à peu près terminé - le reste se passe sous le capot.
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)Sur les deux serveurs, la table proxysql_servers a été correctement définie avec les noms d'hôte des nœuds qui forment le cluster. Nous pouvons également vérifier que les modifications de configuration sont correctement propagées dans le cluster :
Nous avons augmenté le paramètre Max Connections sur l'un des nœuds ProxySQL (10.0 .0.131) et nous pouvons vérifier que l'autre nœud (10.0.0.132) verra la même configuration :
En cas de besoin de déboguer le processus, nous pouvons toujours chercher à le journal ProxySQL (généralement situé dans /var/lib/proxysql/proxysql.log) où nous verrons des informations comme celle-ci :
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:6032Ceci est le journal de 10.0.0.132 où nous pouvons clairement voir qu'un changement de configuration pour la table mysql_servers a été détecté sur 10.0.0.131, puis il a été synchronisé et appliqué sur 10.0.0.132, ce qui le rend synchronisé avec l'autre nœud du cluster.
Comme vous pouvez le constater, la mise en cluster de ProxySQL est un moyen simple mais efficace de s'assurer que sa configuration reste synchronisée et aide considérablement à utiliser des déploiements ProxySQL plus importants. Faites-nous savoir dans les commentaires quelle est votre expérience avec le clustering ProxySQL.
