ProxySQL har fået stor interesse lige nu i MySQL- og MariaDB-databaseverdenen, for ikke at nævne ClickHouse, som hjælper med at gøre sagen for ProxySQL.
Det er sikkert at sige, at ProxySQL er blevet standarddatabaseproxy for MySQL-familien af databaser (såsom Percona Server, Oracle MySQL, Galera Cluster eller endda med MariaDB).
ProxySQL er faktisk en effektiv problemløser med ekstremt rige funktionaliteter, der styrer database klient-server kommunikation; fungerer som mellemvare i en meget avanceret og effektiv tilgang.
Det har gjort det muligt at forme databasetrafikken ved at forsinke, cache eller omskrive forespørgsler på farten. Det kan også bruges til at skabe et miljø, hvor failovers ikke vil påvirke applikationer og vil være gennemsigtige for dem. ProxySQL-fællesskabet er meget lydhørt og bygger konstant rettelser, patches og versionsudgivelser til tiden.
Men hvor effektiv er din ProxySQL-opsætning, og hvordan kan du fastslå, at din opsætning er blevet indstillet korrekt? Denne blog fokuserer på at bestemme, hvor effektive dine ProxySQL-noder er, og hvordan de overvåges effektivt.
Almindelige problemer, du kan støde på med ProxySQL
ProxySQLs standardinstallation leveres med et letvægts, enkelt tuningværktøj, der er i stand til at håndtere gennemsnitlig til tung belastning. Selvom dette kan afhænge af typen af forespørgsler, der sendes til middlewaren, kan det påvirke og begynde at opleve flaskehalse og latenstid.
Latensproblemer
For eksempel kan det være svært at afgøre, hvad der kan føre til forsinkelsesproblemer, hvis du mangler et overvågningssystem. Ligeledes kan du manuelt overvåge eller kontrollere statistikskemaet ligesom nedenfor:
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)Dette giver dig mulighed for at overvåge latenstid baseret på værtsgruppen. Men det tilføjer besværet, medmindre du er nødt til at innovere og udvikle et eller flere scripts, der formår at give dig besked.
Klientforbindelsesfejl
Maksimal forbindelsestimeout på grund af maksimale forbindelser i backend (selve databasenoden) kan føre dig til forvirring, hvis du ikke er i stand til at afgøre, hvad der er hovedkilden til problemet. Du kan dog tjekke statistikdatabasen for at tjekke for sådanne afbrudte forbindelser i klienten eller endda serveren, og den nægtes forbindelser som følger,
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)Det er også ideelt, hvis du kan verificere og kontrollere backend-brugerens maksimale antal forbindelser for at se, hvor mange forbindelsesgrænser den kan åbne eller bruge. For eksempel har jeg følgende i min 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)Langsomme forespørgsler
At identificere de langsomme forespørgsler kan ikke være så svært i ProxySQL, men det kan være ineffektivt, hvis det gøres manuelt. Du kan tjekke dette, hvis du gør manuel med variablen,
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)Selvom det kan give dig nogle tal, kan du tjekke tabellen stats_mysql_query_digest under statistikskemaet, hvis du vil grave dybere. For eksempel nedenfor,
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)
som fanger top 10 langsomme forespørgsler baseret på en stikprøve med 100.
Hukommelsesudnyttelse
Hardwareelementer såsom CPU, Disk og Hukommelse skal overvåges for at sikre, at din ProxySQL fungerer. Det mest afgørende er dog hukommelsen, da ProxySQL vil bruge meget i hukommelsen på grund af forespørgselscache-mekanismen. Som standard er forespørgselscachen, som er afhængig af variablen mysql-query_cache_size_MB, som standard 256 Mib. I den forbindelse kan det komme til en situation, hvor det bruger hukommelse, og du skal bestemme og diagnosticere, om du finder problemer i din ProxySQL-node eller endda bliver bemærket i applikationslaget.
Når du identificerer dette, kan du ende med at tjekke tabellerne i stats_history og statistikskemaerne. Du kan se listen over tabeller, som kan hjælpe dig under diagnosen,
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)Effektiv bestemmelse af ydeevnen af din ProxySQL
Der er flere måder at bestemme ydeevnen af din ProxySQL-node på. Brug af ClusterControl giver dig mulighed for at bestemme dette med enkle, men ligefremme grafer. For eksempel, når ProxySQL er integreret i din klynge, vil du være i stand til at indstille dine forespørgselsregler, ændre brugerens max_connections, bestemme de øverste forespørgsler, ændre en brugerværtsgruppe og give dig ydeevnen for din ProxySQL-node. Se skærmbillederne nedenfor...
Alt, du ser, er beviset på, hvor dygtigt ClusterControl kan give dig indsigt i ydeevnen af din ProxySQL node. Men dette begrænser dig ikke til det. ClusterControl har også rige og kraftfulde dashboards, vi kalder SCUMM, som inkluderer ProxySQL Overview dashboard.
Hvis du har til hensigt at bestemme langsomme forespørgsler, kan du blot kaste et blik på dashboardet. Hvis du tjekker din latensfordeling over de forskellige værtsgrupper, hvor dine backend-noder er tildelt, hjælper det dig med at få et hurtigt indblik i ydeevnen baseret på distribution. Du kan overvåge klient- og serverforbindelserne, hvilket giver dig indsigt i cache-forespørgsler. Vigtigst og ikke mindst, det giver dig den hukommelsesudnyttelse, som ProxySQL node bruger. Se graferne nedenfor...
Disse grafer er en del af dashboardet, som blot hjælper dig med nemt at bestemme ydeevne af din ProxySQL-node.
ClusterControl begrænser dig ikke, når du har at gøre med ProxySQL. Der er også en rig funktion her, hvor du også kan tage en sikkerhedskopi eller importere konfigurationen, hvilket er meget vigtigt, når du har at gøre med høj tilgængelighed for dine ProxySQL-noder.
Konklusion
Det har aldrig været nemmere at overvåge og afgøre, om du har problemer med din ProxySQL. Ligesom i eksemplet med denne blog, fremviser vi ClusterControl som et værktøj, der kan give dig effektivitet og give dig indsigt til at bestemme de udestående problemer, du har at gøre med dine præstationsrelaterede problemer.