アプリケーションとデータベース間のプロキシレイヤーは、通常、高可用性のために複数のプロキシノードで構成されます。これはProxySQLでも同じです。 ProxySQLは、他の最新のプロキシと同様に、ルーティングクエリの複雑なロジックを構築するために使用できます。クエリルールを追加して特定のホストにクエリを送信したり、クエリをキャッシュしたり、バックエンドサーバーを追加および削除したり、ProxySQLおよびMySQLへの接続を許可されているユーザーを管理したりできます。ただし、プロキシ層に多数のProxySQLノードがあると、別の問題が発生します。分散インスタンス間の同期です。ルールやその他のロジックは、インスタンス間で同期して、同じように動作するようにする必要があります。すべてのプロキシがトラフィックを処理しているわけではない場合でも、それらはスタンバイとして機能します。彼らが作業を引き継ぐ必要がある場合に備えて、使用されているインスタンスに最新の構成変更がなくても、驚くことはありません。
これを手動で確認するのは非常に面倒です。すべてのノードを手動で変更します。 Ansible、Chef、Puppetなどのツールを使用して構成を管理できますが、同期プロセスをコーディングしてテストする必要があります。 ClusterControlは、ProxySQLインスタンス間で構成を同期するオプションを通じてここで役立ちますが、高可用性に必要な他のコンポーネント（仮想IPなど）をセットアップおよび管理することもできます。ただし、バージョン1.4.2以降、ProxySQLはネイティブのクラスタリングおよび構成同期メカニズムを提供します。このブログ投稿では、ClusterControlとProxySQLコマンドライン管理インターフェースで実行されるアクションを組み合わせて設定する方法について説明します。
まず、ClusterControlによって展開される一般的なレプリケーション環境を見てみましょう。
スクリーンショットからわかるように、これは3つのProxySQLインスタンスを使用したMySQLレプリケーションのセットアップです。 ProxySQLの高可用性は、常にProxySQLノードの1つに割り当てられるKeepalivedおよび仮想IPを介して実装されます。 ProxySQLクラスタリングを構成するには、いくつかの手順を実行する必要があります。まず、ノード間で情報を交換するためにProxySQLが使用するユーザーを定義する必要があります。既存の管理ユーザーの上に新しいユーザーを定義しましょう：
次に、admin-cluster_passwordおよびadmin-cluster_username設定でそのユーザーを定義する必要があります。
これは、ノードの1つ（10.0.0.126）でのみ実行されています。この構成変更を残りのProxySQLノードに同期させましょう。
前述したように、ClusterControlを使用すると、わずか数ステップでProxySQLノード間の構成を同期できます。ジョブが10.0.0.127と10.0.0.126の同期を終了すると、同期する必要がある最後のノードだけがあります。
この後、ProxySQL管理コマンドラインインターフェイスに小さな変更を加える必要があります。これは通常、ポート6032でアクセスできます。ProxySQLクラスターのノードを定義する'proxysql_servers'テーブルにエントリを作成する必要があります。
>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)ランタイムへの変更をロードした後、ProxySQLはノードの同期を開始する必要があります。クラスターの状態を追跡できる場所がいくつかあります。
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)stats_proxysql_servers_checksumsテーブルには、特に、クラスター内のノードのリスト、同期されるテーブル、テーブルのバージョンとチェックサムが含まれます。チェックサムが一致していない場合、ProxySQLはクラスターピアから最新バージョンを取得しようとします。この表の内容の詳細については、ProxySQLのドキュメントを参照してください。
プロセスに関するもう1つの情報源は、ProxySQLのログです（デフォルトでは、/ 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:6032ご覧のとおり、ここに新しいチェックサムが検出され、同期プロセスが実行されているという情報があります。
ここで少し立ち止まって、ProxySQLが複数のソースからの構成の更新を処理する方法について説明しましょう。まず、ProxySQLはチェックサムを追跡して、構成が変更されたことを検出します。また、発生したタイミングも保存されます。このデータはタイムスタンプとして保存されるため、解像度は1秒です。 ProxySQLには2つの変数があり、変更の同期方法にも影響を与えます。
Cluster_check_interval_ms-ProxySQLが構成の変更をチェックする頻度を決定します。デフォルトでは1000msです。
Cluster_mysql_servers_diffs_before_sync-同期される前に、チェックが構成の変更を検出する必要がある回数を示します。デフォルト設定は3です。
つまり、同じホストで構成を変更する場合でも、4秒未満の頻度で構成を変更すると、前の変更の前に新しい変更が表示されるため、残りのProxySQLノードが同期できない場合があります。同期されました。また、複数のProxySQLインスタンスで構成を変更する場合は、少なくとも4秒の間隔を空けて変更する必要があります。そうしないと、変更の一部が失われ、その結果、構成が分岐します。たとえば、Proxy1にServer1を追加し、2秒後にProxy2にServer2を追加します。他のすべてのプロキシは、Proxy2の構成が新しいことを検出するため、Proxy1での変更を拒否します。 Proxy2での変更から4秒後、すべてのプロキシ（Proxy1を含む）がProxy2から構成をプルします。
クラスタ内通信は同期しておらず、変更を加えたProxySQLノードが失敗した場合、変更が時間どおりに複製されない可能性があります。最善のアプローチは、2つのProxySQLノードで同じ変更を加えることです。このように、両方がまったく同時に失敗しない限り、どちらかが新しい構成を伝播できるようになります。
また、ProxySQLクラスタートポロジは非常に柔軟である可能性があることも注目に値します。この例では、3つのノードがあり、すべてがproxysql_serversテーブルに3つのエントリがあります。このようなノードは、任意のノードに書き込むことができるクラスターを形成し、変更が伝播されます。さらに、「読み取り専用」モードで動作する外部ノードを追加することもできます。つまり、「コア」クラスターに加えられた変更のみを同期しますが、直接実行された変更は伝播しません。自分自身に。新しいノードで必要なのは、proxysql_serversで「コア」クラスターノードを構成することだけです。その結果、それらのノードに接続してデータの変更を取得しますが、クラスターの残りの部分からは照会されません。構成の変更について。この設定を使用して、クラスター内のいくつかのノード、およびメインの「コア」クラスターから構成を取得する他のProxySQLノードで信頼できる情報源を作成できます。
これらすべてに加えて、ProxySQLクラスターはノードの自動再結合をサポートしています。ノードは起動時に構成を同期します。ノードを追加することで簡単にスケールアウトすることもできます。
このブログ投稿で、ProxySQLクラスターを構成する方法についての洞察が得られることを願っています。 ProxySQLクラスターはClusterControlに対して透過的であり、ClusterControlUIから実行する可能性のある操作には影響しません。