ProxySQLは、ProxySQLのケースを作るのに役立つClickHouseは言うまでもなく、MySQLおよびMariaDBデータベースの世界で現在多くの関心を集めています。
ProxySQLは、MySQLファミリーのデータベース（Percona Server、Oracle MySQL、Galera Cluster、さらにはMariaDBなど）のデフォルトのデータベースプロキシになっていると言っても過言ではありません。
ProxySQLは、実際、データベースのクライアント/サーバー通信を管理する非常に豊富な機能を備えた効率的な問題解決ツールです。非常に高度でパフォーマンスの高いアプローチでミドルウェアとして機能します。
クエリをその場で遅延、キャッシュ、または書き換えることにより、データベーストラフィックを形成する機能が可能になりました。また、フェイルオーバーがアプリケーションに影響を与えず、アプリケーションに対して透過的である環境を作成するためにも使用できます。 ProxySQLコミュニティは非常に応答性が高く、修正、パッチ、およびバージョンリリースをタイムリーに常に構築しています。
しかし、ProxySQLのセットアップはどの程度パフォーマンスが高く、セットアップが正しく調整されているかどうかをどのように判断できますか？このブログは、ProxySQLノードのパフォーマンスとそれを効率的に監視する方法を決定することに焦点を当てています。
ProxySQLで発生する可能性のある一般的な問題
ProxySQLのデフォルトのインストールには、平均的な負荷から重い負荷まで処理できる軽量でシンプルなチューニングツールが付属しています。これはミドルウェアに送信されるクエリの種類によって異なりますが、影響を与え、ボトルネックと遅延を経験し始める可能性があります。
たとえば、遅延の問題につながる可能性があるものは、監視システムがないかどうかを判断するのが難しい場合があります。同様に、以下のように統計スキーマを手動で監視または確認できます。
mysql> select * from stats_mysql_connection_pool\G
*************************** 1. row ***************************
hostgroup: 20
srv_host: 192.168.10.225
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 1151
*************************** 2. row ***************************
hostgroup: 20
srv_host: 192.168.10.226
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 470
*************************** 3. row ***************************
hostgroup: 10
srv_host: 192.168.10.227
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 10855
*************************** 4. row ***************************
hostgroup: 40
srv_host: 192.168.10.225
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 1151
*************************** 5. row ***************************
hostgroup: 40
srv_host: 192.168.10.226
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 470
5 rows in set (0.01 sec)これにより、ホストグループに基づいて遅延を監視できます。ただし、通知するスクリプトを革新して開発する必要がない限り、面倒な作業になります。
バックエンド（データベースノード自体）の最大接続による最大接続タイムアウトは、問題の主な原因を特定できない場合に混乱を招く可能性があります。統計データベースをチェックして、クライアントまたはサーバーでそのような中止された接続をチェックし、次のように接続が拒否されているかどうかをチェックできます。
mysql> select * from stats.stats_mysql_global where variable_name like '%connect%';
+-------------------------------------+----------------+
| Variable_Name | Variable_Value |
+-------------------------------------+----------------+
| Client_Connections_aborted | 0 |
| Client_Connections_connected | 205 |
| Client_Connections_created | 10067 |
| Server_Connections_aborted | 44 |
| Server_Connections_connected | 30 |
| Server_Connections_created | 14892 |
| Server_Connections_delayed | 0 |
| Client_Connections_non_idle | 205 |
| Access_Denied_Max_Connections | 0 |
| Access_Denied_Max_User_Connections | 0 |
| MySQL_Monitor_connect_check_OK | 41350 |
| MySQL_Monitor_connect_check_ERR | 92 |
| max_connect_timeouts | 0 |
| Client_Connections_hostgroup_locked | 0 |
| mysql_killed_backend_connections | 0 |
+-------------------------------------+----------------+
15 rows in set (0.01 sec)バックエンドユーザーの最大接続数を確認および確認して、開くまたは使用できる接続制限の数を確認できる場合にも理想的です。たとえば、テストには次のものがあります
mysql> select username, active, transaction_persistent, max_connections from mysql_users;
+---------------+--------+------------------------+-----------------+
| username | active | transaction_persistent | max_connections |
+---------------+--------+------------------------+-----------------+
| proxydemo | 1 | 1 | 10000 |
| proxysql-paul | 1 | 1 | 10000 |
+---------------+--------+------------------------+-----------------+
2 rows in set (0.00 sec)ProxySQLでは遅いクエリを特定することはそれほど難しいことではありませんが、手動で行うと非効率になる可能性があります。変数を使用して手動で行う場合は、これを確認できます
mysql> select * from stats_mysql_global where variable_name like '%slow%';
+---------------+----------------+
| Variable_Name | Variable_Value |
+---------------+----------------+
| Slow_queries | 2 |
+---------------+----------------+
1 row in set (0.00 sec)いくつかの数値を提供できますが、さらに深く掘り下げたい場合は、統計スキーマの下にあるstats_mysql_query_digestテーブルを確認してください。たとえば、以下の
mysql> select count_star,sum_time,(sum_time/count_star)/1000 as average_time_ms,digest_text
-> from stats_mysql_query_digest
-> where count_star > 100 order by average_time_ms desc limit 10;
+------------+----------+-----------------+--------------------------------------+
| count_star | sum_time | average_time_ms | digest_text |
+------------+----------+-----------------+--------------------------------------+
| 884 | 15083961 | 17 | UPDATE sbtest1 SET k=k+? WHERE id=? |
| 930 | 16000111 | 17 | UPDATE sbtest9 SET k=k+? WHERE id=? |
| 914 | 15695810 | 17 | UPDATE sbtest4 SET k=k+? WHERE id=? |
| 874 | 14467420 | 16 | UPDATE sbtest8 SET k=k+? WHERE id=? |
| 904 | 15294520 | 16 | UPDATE sbtest3 SET k=k+? WHERE id=? |
| 917 | 15228077 | 16 | UPDATE sbtest6 SET k=k+? WHERE id=? |
| 907 | 14613238 | 16 | UPDATE sbtest2 SET k=k+? WHERE id=? |
| 900 | 15113004 | 16 | UPDATE sbtest5 SET k=k+? WHERE id=? |
| 917 | 15299381 | 16 | UPDATE sbtest7 SET k=k+? WHERE id=? |
| 883 | 15010119 | 16 | UPDATE sbtest10 SET k=k+? WHERE id=? |
+------------+----------+-----------------+--------------------------------------+
10 rows in set (0.01 sec)
100によるサンプリングに基づいて、遅いクエリのトップ10をキャッチします。
CPU、ディスク、メモリなどのハードウェアアイテムを監視して、ProxySQLのパフォーマンスを確認する必要があります。ただし、最も重要なことはメモリです。これは、ProxySQLがクエリキャッシュメカニズムのためにメモリを大量に使用するためです。デフォルトでは、変数mysql-query_cache_size_MBに依存するクエリキャッシュのデフォルトは256Mibです。その点で、メモリを使用する状況になる可能性があり、ProxySQLノード内で問題が見つかったかどうか、またはアプリケーション層内で気づかれたかどうかを判断して診断する必要があります。
これを特定すると、stats_historyスキーマとstatsスキーマのテーブルをチェックすることになります。診断時に役立つ表のリストを見ることができます
mysql> show tables from stats;
| stats_memory_metrics |
19 rows in set (0.00 sec)
or,
mysql> show tables from stats_history;
+------------------------+
| tables |
+------------------------+
| mysql_connections |
| mysql_connections_day |
| mysql_connections_hour |
| mysql_query_cache |
| mysql_query_cache_day |
| mysql_query_cache_hour |
| system_cpu |
| system_cpu_day |
| system_cpu_hour |
| system_memory |
| system_memory_day |
| system_memory_hour |
+------------------------+
15 rows in set (0.00 sec)ProxySQLノードのパフォーマンスを判断する方法は複数あります。 ClusterControlを使用すると、シンプルでありながら簡単なグラフでこれを判断できます。たとえば、ProxySQLがクラスターに統合されている場合、クエリルールの設定、ユーザーのmax_connectionsの変更、上位のクエリの決定、ユーザーホストグループの変更、およびProxySQLノードのパフォーマンスの提供を行うことができます。以下のスクリーンショットを参照してください...
表示されるのは、ClusterControlがどのように熟練して洞察を提供できるかを証明するものだけです。 ProxySQLノードのパフォーマンス。しかし、これはあなたをそれに限定するものではありません。 ClusterControlには、ProxySQLの概要ダッシュボードを含むSCUMMと呼ばれる豊富で強力なダッシュボードもあります。
遅いクエリを特定する場合は、ダッシュボードを一目見るだけです。バックエンドノードが割り当てられているさまざまなホストグループでのレイテンシの分布を確認すると、分散に基づいてパフォーマンスをすばやく把握するのに役立ちます。クライアントとサーバーの接続を監視して、クエリキャッシュの洞察を提供できます。最も重要なことですが、ProxySQLノードが使用しているメモリ使用率を提供します。以下のグラフを参照してください...
これらのグラフはダッシュボードの一部であり、簡単に判断するのに役立ちます。 ProxySQLノードのパフォーマンス。
ClusterControlは、ProxySQLを処理するときに制限しません。また、ここには豊富な機能があり、ProxySQLノードの高可用性を処理する場合に非常に重要な構成をバックアップまたはインポートすることもできます。
ProxySQLに問題があるかどうかを監視し、判断することがこれまでになく簡単になりました。このブログの例のように、効率を提供し、パフォーマンス関連の問題に対処している未解決の問題を特定するための洞察を提供できるツールとしてClusterControlを紹介しています。