ProxySQLは、MySQLの世界でよく知られているロードバランサーです。トラフィックを制御し、適切と思われる方法でトラフィックを形成できる優れた機能セットが付属しています。専用ノード、アプリケーションホストと同じ場所に配置、サイロアプローチなど、さまざまな方法で展開できます。これらはすべて、正確な環境とビジネス要件によって異なります。一般的な課題は、ほとんどの場合、ProxySQLノードに同じ構成を含めることです。クラスタをスケールアウトして新しいサーバーをProxySQLに追加する場合は、そのサーバーをアクティブなインスタンスだけでなく、すべてのProxySQLインスタンスで表示できるようにする必要があります。これは、質問につながります-すべてのProxySQLノード間で構成の同期を維持する方法は？
すべてのノードを手動で更新してみることができますが、これは間違いなく効率的ではありません。また、AnsibleやChefなどのインフラストラクチャオーケストレーションツールを使用して、ノード全体の構成を既知の状態に保ち、ProxySQLで直接ではなく、環境の整理に使用するツールを使用して変更を加えることもできます。
ClusterControlを使用する場合、ProxySQLインスタンス間で構成を同期できる一連の機能が付属していますが、このソリューションには短所があります。これは手動のアクションであるため、次のことを覚えておく必要があります。構成変更後に実行してください。これを忘れた場合、たとえば、keepalivedが仮想IPを更新されていないProxySQLインスタンスに移動すると、厄介な驚きが生じる可能性があります。
これらの方法はどれも単純でも100％信頼できるものでもありません。状況は、ProxySQLノードの構成が異なり、潜在的に危険である可能性がある場合です。
幸い、ProxySQLには、この問題の解決策であるProxySQLクラスターが付属しています。考え方は非常に単純です。相互に通信し、各インスタンスに含まれる構成のバージョンについて他のユーザーに通知するProxySQLインスタンスのリストを定義できます。構成はバージョン管理されているため、任意のノードの設定を変更すると、構成バージョンが増加します。これにより、構成の同期がトリガーされ、新しいバージョンの構成が、ProxySQLクラスターを形成するすべてのノードに分散および適用されます。
最近のバージョンのClusterControlを使用すると、ProxySQLクラスターを簡単にセットアップできます。 ProxySQLをデプロイするときは、クラスターの一部にしたいすべてのノードに対して「ネイティブクラスタリングを使用する」オプションにチェックマークを付ける必要があります。
これを実行すると、ほぼ完了です。残りは以下で行われます。フード。
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)両方のサーバーで、proxysql_serversテーブルがクラスターを形成するノードのホスト名で適切に設定されました。また、構成の変更がクラスター全体に適切に伝播されていることを確認できます。
ProxySQLノードの1つで最大接続数の設定を増やしました（10.0 .0.131）、他のノード（10.0.0.132）に同じ構成が表示されることを確認できます：
プロセスをデバッグする必要がある場合は、いつでもProxySQLログ（通常は/var/lib/proxysql/proxysql.logにあります）には、次のような情報が表示されます：
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:6032これは10.0.0.132からのログであり、テーブルmysql_serversの構成変更が10.0.0.131で検出され、10.0.0.132で同期および適用され、同期されていることがはっきりとわかります。クラスタ内の他のノードと。
ご覧のとおり、ProxySQLのクラスタリングは、構成の同期を維持するための簡単で効率的な方法であり、より大規模なProxySQLデプロイメントを使用するのに非常に役立ちます。 ProxySQLクラスタリングの経験をコメントでお知らせください。