ProxySQL har fått ett stort intresse just nu i MySQL- och MariaDB-databasvärlden, för att inte tala om ClickHouse som hjälper till att göra fallet för ProxySQL.
Det är säkert att säga att ProxySQL har blivit standarddatabasproxyn för MySQL-familjen av databaser (som Percona Server, Oracle MySQL, Galera Cluster eller till och med med MariaDB).
ProxySQL är i själva verket en effektiv problemlösare med extremt rika funktioner som hanterar databasklient-serverkommunikation; fungerar som mellanvara på ett mycket avancerat och prestandafyllt sätt.
Det har gjort det möjligt att forma databastrafiken genom att fördröja, cachelagra eller skriva om frågor i farten. Det kan också användas för att skapa en miljö där failovers inte påverkar applikationer och kommer att vara transparenta för dem. ProxySQL-communityt är mycket lyhört och bygger ständigt korrigeringar, patchar och versionssläpp i tid.
Men hur effektiv är din ProxySQL-inställning, och hur kan du avgöra att din inställning har ställts in korrekt? Den här bloggen fokuserar på att bestämma hur prestanda dina ProxySQL-noder är och hur man övervakar dem effektivt.
Vanliga problem du kan stöta på med ProxySQL
ProxySQL:s standardinstallation kommer med ett lätt, enkelt inställningsverktyg som kan hantera genomsnittlig till tung belastning. Även om detta kan bero på vilken typ av frågor som skickas till mellanvaran, kan det påverka och börja uppleva flaskhalsar och latens.
Latensproblem
Till exempel, vad som kan leda till latensproblem kan vara svårt att avgöra om du saknar ett övervakningssystem. På samma sätt kan du manuellt övervaka eller kontrollera statistikschemat precis som nedan:
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)Detta låter dig övervaka latens baserat på värdgruppen. Men det ökar besväret såvida du inte måste förnya dig och utveckla ett eller flera skript som kommer att lyckas meddela dig.
Klientanslutningsfel
Maximal timeout för anslutning på grund av maximala anslutningar i backend (databasnoden i sig) kan leda till förvirring om du inte kan avgöra vad som är huvudkällan till problemet. Du kan dock kontrollera statistikdatabasen för att söka efter sådana avbrutna anslutningar i klienten eller till och med servern och den nekas anslutningar enligt följande,
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 är också idealiskt om du kan verifiera och kontrollera backend-användarens maximala antal anslutningar för att se hur många anslutningsgränser den kan öppna eller använda. Jag har till exempel följande i mitt 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)Långsamma frågor
Att identifiera de långsamma frågorna kan inte vara så svårt i ProxySQL, men det kan vara ineffektivt om det görs manuellt. Du kan kontrollera detta om du gör manuellt med variabeln,
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)Även om det kan ge dig några siffror, kan du kolla i tabellen stats_mysql_query_digest under statistikschemat om du vill gräva djupare. Till exempel nedan,
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 fångar topp 10 långsamma frågor baserat på ett urval med 100.
Minnesanvändning
Hårdvaruobjekt som CPU, disk och minne måste övervakas för att säkerställa att din ProxySQL fungerar. Det mest avgörande är dock minnet, eftersom ProxySQL kommer att använda hårt i minnet på grund av frågecache-mekanismen. Som standard är frågecachen, som är beroende av variabeln mysql-query_cache_size_MB, 256 Mib. Med det avseendet kan det komma till en situation där det använder minne och du måste avgöra och diagnostisera om du hittar problem i din ProxySQL-nod eller till och med upptäcks i applikationslagret.
När du identifierar detta kan det sluta med att du kontrollerar tabellerna i stats_history och statistikscheman. Du kan se listan med tabeller som kan hjälpa 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)Bestämma effektivt prestanda för din ProxySQL
Det finns flera sätt att bestämma prestandan för din ProxySQL-nod. Att använda ClusterControl ger dig möjligheten att avgöra detta med enkla men okomplicerade grafer. Till exempel, när ProxySQL är integrerad i ditt kluster, kommer du att kunna ställa in dina frågeregler, ändra användarens max_connections, bestämma de vanligaste frågorna, ändra en användarvärdgrupp och ge dig prestanda för din ProxySQL-nod. Se skärmdumparna nedan...
Allt du ser är beviset på hur skickligt ClusterControl kan ge dig insikter om prestanda för din ProxySQL-nod. Men detta begränsar dig inte till det. ClusterControl har också rika och kraftfulla dashboards som vi kallar SCUMM, som inkluderar ProxySQL Overview dashboard.
Om du tänker bestämma långsamma frågor kan du helt enkelt ta en blick till instrumentpanelen. Att kontrollera din latensfördelning över de olika värdgrupperna där dina backend-noder är tilldelade hjälper dig att få en snabb inblick i prestandan baserat på distribution. Du kan övervaka klient- och serveranslutningarna, vilket ger dig cache-insikter. Viktigast och inte minst, det ger dig minnesutnyttjandet som ProxySQL-noden använder. Se graferna nedan...
Dessa grafer är en del av instrumentpanelen som helt enkelt hjälper dig att enkelt fastställa prestanda för din ProxySQL-nod.
ClusterControl begränsar dig inte när du hanterar ProxySQL. Det finns också en rik funktion här där du också kan ta en säkerhetskopia eller importera konfigurationen, vilket är mycket viktigt när du har att göra med hög tillgänglighet för dina ProxySQL-noder.
Slutsats
Det har aldrig varit lättare att övervaka och avgöra om du har några problem med din ProxySQL. Liksom i exemplet med den här bloggen visar vi upp ClusterControl som ett verktyg som kan ge dig effektivitet och ge dig insikter för att avgöra vilka utestående problem som du har att göra med dina prestationsrelaterade problem.