Une couche proxy entre les applications et les bases de données se compose généralement de plusieurs nœuds proxy pour une haute disponibilité. Ce n'est pas différent pour ProxySQL. ProxySQL, tout comme les autres proxys modernes, peut être utilisé pour créer une logique complexe pour le routage des requêtes. Vous pouvez ajouter des règles de requête pour envoyer des requêtes à des hôtes particuliers, vous pouvez mettre en cache des requêtes, vous pouvez ajouter et supprimer des serveurs principaux ou gérer les utilisateurs autorisés à se connecter à ProxySQL et MySQL. Cependant, de nombreux nœuds ProxySQL dans la couche proxy introduisent un autre problème :la synchronisation entre les instances distribuées. Toutes les règles ou autres logiques doivent être synchronisées entre les instances, pour s'assurer qu'elles se comportent de la même manière. Même si tous les proxys ne gèrent pas le trafic, ils fonctionnent toujours en veille. Au cas où ils auraient besoin de reprendre le travail, vous ne voulez pas de surprises si l'instance utilisée n'a pas les modifications de configuration les plus récentes.
Il est assez fastidieux de s'en assurer manuellement - d'effectuer les modifications à la main sur tous les nœuds. Vous pouvez utiliser des outils comme Ansible, Chef ou Puppet pour gérer les configurations, mais le processus de synchronisation doit être codé et testé. ClusterControl peut vous aider ici grâce à une option de synchronisation des configurations entre les instances ProxySQL, mais il peut également configurer et gérer les autres composants requis pour la haute disponibilité, par exemple, l'adresse IP virtuelle. Mais à partir de la version 1.4.2, ProxySQL propose un mécanisme natif de clustering et de synchronisation de la configuration. Dans cet article de blog, nous verrons comment le configurer avec un mélange d'actions prises dans l'interface d'administration de ligne de commande ClusterControl et ProxySQL.
Tout d'abord, examinons un environnement de réplication typique déployé par ClusterControl.
Comme vous pouvez le voir sur la capture d'écran, il s'agit d'une configuration de réplication MySQL avec trois instances ProxySQL. La haute disponibilité de ProxySQL est implémentée via Keepalived et une adresse IP virtuelle qui est toujours attribuée à l'un des nœuds ProxySQL. Il y a quelques étapes que nous devons suivre pour configurer le clustering ProxySQL. Tout d'abord, nous devons définir quel utilisateur ProxySQL doit utiliser pour échanger des informations entre les nœuds. Définissons-en un nouveau en plus de l'utilisateur administratif existant :
Ensuite, nous devons définir cet utilisateur dans les paramètres admin-cluster_password et admin-cluster_username.
Cela a été fait sur un seul des nœuds (10.0.0.126). Synchronisons ce changement de configuration avec les nœuds ProxySQL restants.
Comme nous l'avons indiqué, ClusterControl vous permet de synchroniser la configuration entre les nœuds ProxySQL en quelques étapes seulement. Lorsque la tâche a terminé la synchronisation de 10.0.0.127 avec 10.0.0.126, il ne reste plus que le dernier nœud à synchroniser.
Après cela, nous devons apporter une petite modification à l'interface de ligne de commande administrative ProxySQL, qui est généralement accessible sur le port 6032. Nous devons créer des entrées dans la table 'proxysql_servers' qui définiraient les nœuds de notre cluster ProxySQL.
mysql> INSERT INTO proxysql_servers (hostname) VALUES ('10.0.0.126'), ('10.0.0.127'), ('10.0.0.128');
Query OK, 3 rows affected (0.00 sec)mysql> LOAD PROXYSQL SERVERS TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)mysql> SAVE PROXYSQL SERVERS TO DISK;
Query OK, 0 rows affected (0.01 sec)Après avoir chargé la modification dans l'environnement d'exécution, ProxySQL doit commencer à synchroniser les nœuds. Il existe plusieurs endroits où vous pouvez suivre l'état du cluster.
mysql> SELECT * FROM stats_proxysql_servers_checksums;
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
| hostname | port | name | version | epoch | checksum | changed_at | updated_at | diff_check |
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
| 10.0.0.128 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_query_rules | 2 | 1539772933 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_servers | 4 | 1539772933 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_users | 2 | 1539772933 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | proxysql_servers | 2 | 1539773835 | 0x8EB13E2B48C3FDB0 | 1539773835 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_query_rules | 3 | 1539773719 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_servers | 5 | 1539773719 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_users | 3 | 1539773719 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | proxysql_servers | 2 | 1539773812 | 0x8EB13E2B48C3FDB0 | 1539773813 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_query_rules | 1 | 1539770578 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_servers | 3 | 1539771053 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_users | 1 | 1539770578 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | proxysql_servers | 2 | 1539773546 | 0x8EB13E2B48C3FDB0 | 1539773546 | 1539773916 | 0 |
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
18 rows in set (0.00 sec)La table stats_proxysql_servers_checksums contient, entre autres, une liste des nœuds du cluster, des tables synchronisées, des versions et de la somme de contrôle de la table. Si la somme de contrôle n'est pas conforme, ProxySQL tentera d'obtenir la dernière version auprès d'un homologue du cluster. Des informations plus détaillées sur le contenu de cette table sont disponibles dans la documentation ProxySQL.
Une autre source d'informations sur le processus est le journal de ProxySQL (par défaut, il se trouve dans /var/lib/proxysql/proxysql.log).
2018-10-17 11:00:25 [INFO] Cluster: detected a new checksum for mysql_query_rules from peer 10.0.0.126:6032, version 2, epoch 1539774025, checksum 0xD615D5416F61AA72 . Not syncing yet …
2018-10-17 11:00:27 [INFO] Cluster: detected a peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025, diff_check 3. Own version: 2, epoch: 1539772933. Proceeding with remote sync
2018-10-17 11:00:28 [INFO] Cluster: detected a peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025, diff_check 4. Own version: 2, epoch: 1539772933. Proceeding with remote sync
2018-10-17 11:00:28 [INFO] Cluster: detected peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025
2018-10-17 11:00:28 [INFO] Cluster: Fetching MySQL Query Rules from peer 10.0.0.126:6032 started
2018-10-17 11:00:28 [INFO] Cluster: Fetching MySQL Query Rules from peer 10.0.0.126:6032 completed
2018-10-17 11:00:28 [INFO] Cluster: Loading to runtime MySQL Query Rules from peer 10.0.0.126:6032
2018-10-17 11:00:28 [INFO] Cluster: Saving to disk MySQL Query Rules from peer 10.0.0.126:6032Comme vous pouvez le voir, nous avons ici des informations indiquant qu'une nouvelle somme de contrôle a été détectée et que le processus de synchronisation est en place.
Arrêtons-nous un instant ici et discutons de la façon dont ProxySQL gère les mises à jour de configuration à partir de plusieurs sources. Tout d'abord, ProxySQL suit les sommes de contrôle pour détecter quand une configuration a changé. Il stocke également quand cela s'est produit - ces données sont stockées sous forme d'horodatage, elles ont donc une résolution d'une seconde. ProxySQL a deux variables qui ont également un impact sur la façon dont les modifications sont synchronisées.
Cluster_check_interval_ms - il détermine la fréquence à laquelle ProxySQL doit vérifier les modifications de configuration. Par défaut, il est de 1 000 ms.
Cluster_mysql_servers_diffs_before_sync - il nous indique combien de fois une vérification doit détecter un changement de configuration avant d'être synchronisée. Le paramètre par défaut est 3.
Cela signifie que, même si vous faites un changement de configuration sur le même hôte, si vous le faites moins souvent que 4 secondes, les nœuds ProxySQL restants ne pourront peut-être pas le synchroniser car un nouveau changement apparaîtra avant le précédent était synchronisé. Cela signifie également que si vous apportez des modifications de configuration sur plusieurs instances ProxySQL, vous devez les faire avec au moins une pause de 4 secondes entre elles, sinon certaines des modifications seront perdues et, par conséquent, les configurations divergeront. Par exemple, vous ajoutez Server1 sur Proxy1 , et après 2 secondes vous ajoutez Server2 sur Proxy2 . Tous les autres proxys rejetteront la modification sur Proxy1 car ils détecteront que Proxy2 a une configuration plus récente. 4 secondes après le changement sur Proxy2, tous les proxys (y compris Proxy1) extrairont la configuration de Proxy2.
Comme la communication intra-cluster n'est pas synchrone et si un nœud ProxySQL auquel vous avez apporté les modifications échoue, les modifications peuvent ne pas être répliquées à temps. La meilleure approche consiste à effectuer la même modification sur deux nœuds ProxySQL. De cette façon, à moins que les deux échouent exactement en même temps, l'un d'eux pourra propager la nouvelle configuration.
Il convient également de noter que la topologie du cluster ProxySQL peut être assez flexible. Dans notre cas, nous avons trois nœuds, tous ont trois entrées dans la table proxysql_servers. Ces nœuds forment le cluster où vous pouvez écrire sur n'importe quel nœud et les modifications seront propagées. En plus de cela, il est possible d'ajouter des nœuds externes qui fonctionneraient en mode "lecture seule", ce qui signifie qu'ils ne synchroniseraient que les modifications apportées au cluster "core" mais qu'ils ne propageraient pas les modifications effectuées directement. sur eux-mêmes. Tout ce dont vous avez besoin sur le nouveau nœud est de n'avoir que les nœuds de cluster « principaux » configurés dans proxysql_servers et, par conséquent, il se connectera à ces nœuds et obtiendra les modifications de données, mais il ne sera pas interrogé par le reste du cluster. pour ses changements de configuration. Cette configuration pourrait être utilisée pour créer une source de vérité avec plusieurs nœuds dans le cluster, et d'autres nœuds ProxySQL, qui obtiennent simplement la configuration du cluster « principal » principal.
En plus de tout cela, le cluster ProxySQL prend en charge la réintégration automatique des nœuds - ils synchroniseront leur configuration au démarrage. Il peut également être facilement mis à l'échelle en ajoutant plus de nœuds.
Nous espérons que cet article de blog vous donnera un aperçu de la façon dont le cluster ProxySQL peut être configuré. Le cluster ProxySQL sera transparent pour ClusterControl et n'aura aucune incidence sur les opérations que vous voudrez peut-être exécuter à partir de l'interface utilisateur de ClusterControl.
