ProxySQLは、MySQLに最適なプロキシの1つです。これにより、データベース管理者向けに多くのオプションが導入されました。クエリをその場で遅延、キャッシュ、または書き換えることにより、データベーストラフィックを形成することが可能になりました。また、フェイルオーバーがアプリケーションに影響を与えず、アプリケーションに対して透過的である環境を作成するためにも使用できます。以前のブログ投稿で最も重要なProxySQL機能についてはすでに説明しました：
- クエリをキャッシュするためにClusterControlとProxySQLを使用する方法
- ClusterControlとProxySQLを使用してSQLファイアウォールを構築する方法
- ProxySQLクラスターをデプロイする方法
- 高可用性を実現するためにProxySQLを使用してMySQLレプリケーション環境を簡単にデプロイする方法
ProxySQLをMySQLおよびMariaDBのセットアップでどのように使用できるかを示すチュートリアルもあります。
ごく最近、ProxySQL 2.0.3がリリースされ、2.0シリーズのパッチリリースになりました。バグは修正されており、2.0ラインはそれに値する牽引力を獲得し始めているようです。このブログ投稿では、ProxySQL2.0で導入された主な変更点について説明します。
GTIDを使用した因果関係の読み取り
レプリケーションラグに対処する必要があり、レプリケーションラグの影響を受ける書き込み後の読み取りシナリオに苦労したすべての人は、この機能に間違いなく非常に満足しています。これまでのところ、MySQLレプリケーション環境では、原因となる読み取りを確実にする唯一の方法は、マスターから読み取ることでした（非同期または半同期レプリケーションを使用するかどうかは関係ありません）。もう1つのオプションは、Galeraを選択することでした。これには、常にのように、因果関係の読み取りを強制するオプションがありました（最初はwsrep-causal-readsでしたが、現在はwsrep-sync-waitです）。ごく最近（8.0.14）、MySQLグループレプリケーションにも同様の機能が追加されました。ただし、通常のレプリケーションだけでは、この問題に対処できません。幸いなことに、ProxySQLがここにあり、クエリルールごとに、そのクエリルールに一致するホストグループが読み取る内容を一貫して定義するオプションが提供されます。実装にはProxySQLbinlogリーダーが付属しており、MySQL5.7以降のROWbinlog形式で動作します。 MariaDBに必要な機能がないため、OracleMySQLのみがサポートされています。この機能とその技術的な詳細は、ProxySQLの公式ブログで説明されています。
フロントエンド接続用のSSL
ProxySQLは常にバックエンドSSL接続をサポートしていましたが、クライアントからの接続に対するSSL暗号化がありませんでした。推奨される展開パターンがアプリケーションノードにProxySQLを併置し、安全なUnixソケットを使用してアプリからプロキシに接続することであったことを考えると、これはそれほど大きな問題ではありませんでした。これは、特にクエリのキャッシュにProxySQLを使用する場合は、依然として推奨事項です（UnixソケットはTCP接続よりも高速であり、ローカルソケットでも、キャッシュを使用すると、不要な遅延が発生しないようにすることができます）。良い点は、ProxySQL 2.0では、着信接続にSSLサポートが導入されたため、選択肢が増えたことです。 mysql-have_sslを「true」に設定することで簡単に有効にできます。 SSLを有効にしても、パフォーマンスに許容できない影響はありません。逆に、ProxySQLの公式ブログの結果によると、パフォーマンスの低下は非常に低いです。
ガレラクラスターのネイティブサポート
Galera Clusterは、ほぼ最初からProxySQLによってサポートされてきましたが、これまでのところ、ProxySQLの内部スケジューラから（通常は）呼び出された外部スクリプトを介してサポートされていました。 ProxySQL構成が適切であり、ライター（または複数のライター）がライターホストグループで正しく検出および構成されていることを確認するのは、スクリプトの責任でした。スクリプトは、Galeraノードが持つ可能性のあるさまざまな状態（プライマリ、非プライマリ、同期、ドナー/非同期、参加、参加）を検出し、それに応じてノードを使用可能かどうかとしてマークすることができました。主な問題は、元のスクリプトがBashで記述された概念実証以外のものとして意図されていなかったことです。それでも、ProxySQLと一緒に配布されるにつれて、外部の貢献者によって変更され、改善され始めました。他の人（Perconaなど）は、ソフトウェアにバンドルされた独自のスクリプトの作成を検討しました。 ProxySQLリポジトリのスクリプトにいくつかの修正が導入され、スクリプトのPerconaバージョンにいくつかの修正が導入されました。これは混乱を招き、一般的に使用されるすべてのスクリプトがユースケースの95％を処理しましたが、Galeraクラスターが使用する可能性のあるさまざまな状況や変数を実際にカバーするものはありませんでした。幸い、ProxySQL2.0にはGaleraClusterのネイティブサポートが付属しています。これにより、ProxySQLはMySQLレプリケーション、MySQLグループレプリケーション、そして現在はGaleraClusterを内部的にサポートします。それが行われる方法は非常に似ています。一見明確ではない可能性があるため、この機能の構成について説明します。
MySQLレプリケーションおよびMySQLグループレプリケーションと同様に、テーブルはProxySQLで作成されています：
mysql> show create table mysql_galera_hostgroups\G
*************************** 1. row ***************************
table: mysql_galera_hostgroups
Create Table: CREATE TABLE mysql_galera_hostgroups (
writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY,
backup_writer_hostgroup INT CHECK (backup_writer_hostgroup>=0 AND backup_writer_hostgroup<>writer_hostgroup) NOT NULL,
reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND backup_writer_hostgroup<>reader_hostgroup AND reader_hostgroup>0),
offline_hostgroup INT NOT NULL CHECK (offline_hostgroup<>writer_hostgroup AND offline_hostgroup<>reader_hostgroup AND backup_writer_hostgroup<>offline_hostgroup AND offline_hostgroup>=0),
active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 1,
max_writers INT NOT NULL CHECK (max_writers >= 0) DEFAULT 1,
writer_is_also_reader INT CHECK (writer_is_also_reader IN (0,1,2)) NOT NULL DEFAULT 0,
max_transactions_behind INT CHECK (max_transactions_behind>=0) NOT NULL DEFAULT 0,
comment VARCHAR,
UNIQUE (reader_hostgroup),
UNIQUE (offline_hostgroup),
UNIQUE (backup_writer_hostgroup))
1 row in set (0.00 sec)構成する設定は多数あり、それらを1つずつ確認します。まず、4つのホストグループがあります：
- Writer_hostgroup-「max_writers」設定までのすべてのライター（read_only =0）が含まれます。デフォルトでは、ライターは1人だけです
- Backup_writer_hostgroup-「max_writers」がwriter_hostgroupに追加された後に残る残りのライター（read_only =0）が含まれます
- Reader_hostgroup-リーダーが含まれ（read_only =1）、「writer_is_also_reader」設定に従ってバックアップライターが含まれる場合もあります
- Offline_hostgroup-使用できないと見なされたノードが含まれています（オフラインまたはトラフィックを処理できない状態になっている）
その後、残りの設定があります：
- アクティブ-mysql_galera_hostgroupsのエントリがアクティブかどうか
- Max_writers-最大で何個のノードをwriter_hostgroupに入れることができますか
- Writer_is_also_reader-0に設定すると、ライター（read_only =0）はreader_hostgroupに入れられません。 1に設定すると、ライター（read_only =0）がreader_hostgroupに配置されます。 2に設定すると、backup_writer_hostgroupのノードがreader_hostgroupに配置されます。これは少し複雑なので、このブログ投稿の後半で例を示します
- Max_transactions_behind-許容可能な最大キューであるwsrep_local_recv_queueに基づきます。ノードのキューがmax_transactions_behindを超えると、指定されたノードはSHUNNEDとしてマークされ、トラフィックに使用できなくなります
主な驚きは、ProxySQLに含まれているスクリプトの動作とは異なる、リーダーの処理である可能性があります。まず、覚えておく必要があるのは、ProxySQLがread_only =1を使用して、ノードがリーダーであるかどうかを判断するという事実です。これはレプリケーション設定では一般的であり、Galeraでは一般的ではありません。したがって、ほとんどの場合、「writer_is_also_reader」設定を使用して、リーダーをreader_hostgroupに追加する方法を構成する必要があります。 3つのGaleraノードを考えてみましょう。それらはすべてread_only=0です。すべての書き込みを1つのノードに向けたいので、max_writers=1もあります。 mysql_galera_hostgroupsを次のように構成しました：
SELECT * FROM mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 30
reader_hostgroup: 20
offline_hostgroup: 40
active: 1
max_writers: 1
writer_is_also_reader: 0
max_transactions_behind: 0
comment: NULL
1 row in set (0.00 sec)すべてのオプションを見ていきましょう：
writer_is_also_reader =0
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
3 rows in set (0.00 sec)この結果は、スクリプトで表示されるものとは異なります。残りのノードはリーダーとしてマークされます。ここでは、ライターをリーダーにしたくない場合、およびread_only =1のノードがない場合、リーダーは構成されません。 1つのライター（max_writersによる）、backup_writer_hostgroup内の残りのノード。
writer_is_also_reader =1
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 20 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
6 rows in set (0.00 sec)ここでは、ライターがリーダーとして機能するようにしたいので、すべてのライター（アクティブおよびバックアップ）がreader_hostgroupに配置されます。
writer_is_also_reader =2
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
5 rows in set (0.00 sec)これは、アクティブなライターに読み取りを処理させたくない場合の設定です。この場合、backup_writer_hostgroupのノードのみが読み取りに使用されます。 max_writersを他の値に設定すると、リーダーの数が変わることにも注意してください。 3に設定した場合、バックアップライターは存在しません（すべてのノードがライターホストグループに含まれることになります）。したがって、ここでも、リーダーホストグループにノードはありません。
もちろん、ホストグループの構成に応じてクエリルールを構成することをお勧めします。ここではこのプロセスについては説明しません。ProxySQLブログでどのように実行できるかを確認できます。 Docker環境でどのように機能するかをテストしたい場合は、DockerでGaleraクラスターとProxySQL2.0を実行する方法を説明したブログがあります。
その他の変更
上記で説明したのは、ProxySQL2.0の最も顕著な改善点です。変更ログによると、他にもたくさんあります。言及する価値があるのは、クエリキャッシュに関する改善（たとえば、PROXYSQL FLUSH QUERY CACHEの追加）と、ProxySQLがsuper_read_onlyに依存してレプリケーションセットアップのマスターとスレーブを決定できるようにする変更です。
ProxySQL 2.0での変更のこの短い概要が、使用するProxySQLのバージョンを決定するのに役立つことを願っています。 1.4ブランチは、新しい機能が追加されなくても、引き続き維持されることに注意してください。