ProxySQL hat gerade in der Welt der MySQL- und MariaDB-Datenbanken großes Interesse geweckt, ganz zu schweigen von ClickHouse, das dabei hilft, für ProxySQL zu werben.
Man kann mit Sicherheit sagen, dass ProxySQL zum Standard-Datenbank-Proxy für die MySQL-Datenbankfamilie geworden ist (wie Percona Server, Oracle MySQL, Galera Cluster oder sogar mit MariaDB).
ProxySQL ist in der Tat ein effizienter Problemlöser mit extrem umfangreichen Funktionalitäten, die die Datenbank-Client-Server-Kommunikation verwalten; fungiert als Middleware in einem sehr fortschrittlichen und performanten Ansatz.
Es hat die Fähigkeit ermöglicht, den Datenbankverkehr zu formen, indem Abfragen im laufenden Betrieb verzögert, zwischengespeichert oder umgeschrieben werden. Es kann auch verwendet werden, um eine Umgebung zu schaffen, in der Failover Anwendungen nicht beeinträchtigen und für sie transparent sind. Die ProxySQL-Community ist sehr reaktionsschnell und erstellt ständig zeitnah Fixes, Patches und Versionsveröffentlichungen.
Aber wie leistungsfähig ist Ihr ProxySQL-Setup und wie können Sie feststellen, ob Ihr Setup richtig abgestimmt wurde? Dieser Blog konzentriert sich darauf, festzustellen, wie leistungsfähig Ihre ProxySQL-Knoten sind und wie sie effizient überwacht werden können.
Häufige Probleme, die bei ProxySQL auftreten können
Die Standardinstallation von ProxySQL enthält ein leichtes, einfaches Tuning-Tool, das mittlere bis hohe Last bewältigen kann. Obwohl dies von der Art der an die Middleware gesendeten Abfragen abhängen kann, kann es sich auswirken und zu Engpässen und Latenzen führen.
Latenzprobleme
Zum Beispiel, was zu Latenzproblemen führen kann, kann schwer zu bestimmen sein, wenn Sie kein Überwachungssystem haben. Ebenso können Sie das Statistikschema wie folgt manuell überwachen oder überprüfen:
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)Dies ermöglicht Ihnen, die Latenz basierend auf der Hostgruppe zu überwachen. Aber es erhöht den Aufwand, es sei denn, Sie müssen innovativ sein und ein oder mehrere Skripts entwickeln, die es schaffen, Sie zu benachrichtigen.
Client-Verbindungsfehler
Maximale Verbindungszeitüberschreitung aufgrund maximaler Verbindungen im Backend (Datenbankknoten selbst) kann Sie in Verlegenheit bringen, wenn Sie nicht feststellen können, was die Hauptursache des Problems ist. Sie können jedoch die Statistikdatenbank überprüfen, um nach solchen abgebrochenen Verbindungen im Client oder sogar auf dem Server zu suchen, und wie folgt werden Verbindungen verweigert,
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)Es ist auch ideal, wenn Sie die maximale Anzahl von Verbindungen des Backend-Benutzers überprüfen und überprüfen können, um zu sehen, wie viele Verbindungslimits er öffnen oder verwenden kann. Zum Beispiel habe ich Folgendes in meinem Test,
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)Langsame Abfragen
Das Identifizieren der langsamen Abfragen kann in ProxySQL nicht so schwierig sein, aber es kann ineffizient sein, wenn es manuell durchgeführt wird. Sie können dies überprüfen, wenn Sie die Variable manuell verwenden,
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)Das kann Ihnen zwar einige Zahlen liefern, aber Sie können in der Tabelle stats_mysql_query_digest unter dem Statistikschema nachsehen, wenn Sie tiefer graben möchten. Zum Beispiel unten,
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)
das die 10 langsamsten Suchanfragen erfasst, basierend auf einer Stichprobe von 100.
Speichernutzung
Hardwareelemente wie CPU, Festplatte und Arbeitsspeicher müssen überwacht werden, um sicherzustellen, dass Ihr ProxySQL leistungsfähig ist. Das Wichtigste ist jedoch der Arbeitsspeicher, da ProxySQL den Arbeitsspeicher aufgrund des Abfrage-Cache-Mechanismus stark beansprucht. Standardmäßig beträgt der Abfrage-Cache, der von der Variable mysql-query_cache_size_MB abhängt, 256 Mib. In diesem Zusammenhang kann es zu einer Situation kommen, in der Speicher verwendet wird und Sie feststellen und diagnostizieren müssen, ob Sie Probleme in Ihrem ProxySQL-Knoten finden oder sogar in der Anwendungsschicht bemerkt werden.
Wenn Sie dies identifizieren, überprüfen Sie möglicherweise die Tabellen in den Schemata stats_history und stats. Sie können die Liste der Tabellen sehen, die Ihnen bei der Diagnose helfen können,
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)Effiziente Ermittlung der Leistung Ihres ProxySQL
Es gibt mehrere Möglichkeiten, die Leistung Ihres ProxySQL-Knotens zu bestimmen. Die Verwendung von ClusterControl bietet Ihnen die Möglichkeit, dies mit einfachen, aber unkomplizierten Diagrammen zu bestimmen. Wenn beispielsweise ProxySQL in Ihren Cluster integriert ist, können Sie Ihre Abfrageregeln festlegen, die max_connections von Benutzern ändern, die häufigsten Abfragen bestimmen, eine Benutzerhostgruppe ändern und Ihnen die Leistung Ihres ProxySQL-Knotens bereitstellen. Siehe Screenshots unten...
Alles, was Sie sehen, ist der Beweis dafür, wie kompetent ClusterControl Ihnen Einblicke geben kann die Leistung Ihres ProxySQL-Knotens. Aber das beschränkt Sie nicht darauf. ClusterControl verfügt auch über reichhaltige und leistungsstarke Dashboards, die wir SCUMM nennen, einschließlich des ProxySQL-Übersichts-Dashboards.
Wenn Sie langsame Abfragen ermitteln möchten, können Sie einfach einen Blick auf das Dashboard werfen. Die Überprüfung Ihrer Latenzverteilung über die verschiedenen Hostgruppen, denen Ihre Backend-Knoten zugewiesen sind, hilft Ihnen, einen schnellen Einblick in die Leistung basierend auf der Verteilung zu erhalten. Sie können die Client- und Serververbindungen überwachen und Einblicke in den Abfrage-Cache erhalten. Am wichtigsten und nicht zuletzt gibt es Ihnen die Speichernutzung an, die der ProxySQL-Knoten verwendet. Siehe die Grafiken unten...
Diese Grafiken sind Teil des Dashboards, das Ihnen einfach dabei hilft, die Leistung Ihres ProxySQL-Knotens.
ClusterControl schränkt Sie im Umgang mit ProxySQL nicht ein. Außerdem gibt es hier eine reichhaltige Funktion, mit der Sie auch ein Backup erstellen oder die Konfiguration importieren können, was sehr wichtig ist, wenn Sie mit Hochverfügbarkeit für Ihre ProxySQL-Knoten arbeiten.
Fazit
Es war noch nie so einfach, Probleme mit Ihrem ProxySQL zu überwachen und festzustellen. Wie im Beispiel dieses Blogs präsentieren wir ClusterControl als ein Tool, das Ihnen Effizienz bietet und Ihnen Einblicke gibt, um die ausstehenden Probleme zu ermitteln, die Sie mit Ihren leistungsbezogenen Problemen zu tun haben.
