ProxySQL heeft op dit moment veel belangstelling gekregen in de MySQL- en MariaDB-databasewereld, om nog maar te zwijgen van ClickHouse, dat helpt om ProxySQL te verdedigen.
Het is veilig om te zeggen dat ProxySQL de standaard databaseproxy is geworden voor de MySQL-familie van databases (zoals Percona Server, Oracle MySQL, Galera Cluster of zelfs met MariaDB).
ProxySQL is in feite een efficiënte probleemoplosser met extreem rijke functionaliteiten die database-client-server-communicatie beheren; optreden als middleware in een zeer geavanceerde en performante aanpak.
Het heeft de mogelijkheid mogelijk gemaakt om het databaseverkeer vorm te geven door query's on-the-fly uit te stellen, in de cache op te slaan of te herschrijven. Het kan ook worden gebruikt om een omgeving te creëren waarin failovers geen invloed hebben op applicaties en voor hen transparant zijn. De ProxySQL-gemeenschap reageert zeer snel en bouwt voortdurend fixes, patches en versie-releases op een tijdige basis.
Maar hoe performant is uw ProxySQL-configuratie en hoe kunt u bepalen of uw installatie correct is afgesteld? Deze blog richt zich op het bepalen hoe goed uw ProxySQL-knooppunten zijn en hoe u deze efficiënt kunt controleren.
Veelvoorkomende problemen die u kunt tegenkomen met ProxySQL
De standaardinstallatie van ProxySQL wordt geleverd met een lichtgewicht, eenvoudig afstemmingshulpmiddel dat gemiddelde tot zware belasting aankan. Hoewel dit kan afhangen van het type query's dat naar de middleware wordt gestuurd, kan het van invloed zijn op knelpunten en latentie en deze gaan ervaren.
Latentieproblemen
Wat kan leiden tot latentieproblemen kan bijvoorbeeld moeilijk te bepalen zijn als je geen monitoringsysteem hebt. Op dezelfde manier kunt u het statistiekenschema handmatig controleren of controleren, zoals hieronder:
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)Hiermee kunt u de latentie volgen op basis van de hostgroep. Maar het zorgt voor nog meer gedoe, tenzij je moet innoveren en script(s) moet ontwikkelen die je op de hoogte kunnen stellen.
Klantverbindingsfouten
Maximale verbindingstime-out vanwege maximale verbindingen in de backend (databaseknooppunt zelf) kan tot verwarring leiden als u niet kunt bepalen wat de belangrijkste oorzaak van het probleem is. U kunt echter de statistiekendatabase controleren om te controleren op dergelijke afgebroken verbindingen in de client of zelfs de server en de verbindingen worden als volgt geweigerd,
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)Het is ook ideaal als u het maximale aantal verbindingen van de backend-gebruiker kunt verifiëren en controleren om te zien hoeveel verbindingslimieten het kan openen of gebruiken. Ik heb bijvoorbeeld het volgende in mijn 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)Langzame zoekopdrachten
Het identificeren van trage zoekopdrachten kan niet zo moeilijk zijn in ProxySQL, maar het kan inefficiënt zijn als het handmatig wordt gedaan. U kunt dit controleren als u handmatig met de variabele doet,
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)Hoewel dat je wat cijfers kan opleveren, kun je de tabel stats_mysql_query_digest onder het statistiekenschema bekijken als je dieper wilt graven. Bijvoorbeeld hieronder,
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)
die top 10 langzame zoekopdrachten vangt op basis van een steekproef van 100.
Geheugengebruik
Hardware-items zoals CPU, schijf en geheugen moeten worden gecontroleerd om ervoor te zorgen dat uw ProxySQL werkt. Het meest cruciale is echter het geheugen, omdat ProxySQL het geheugen zwaar zal gebruiken vanwege het querycachemechanisme. Standaard is de querycache, die afhankelijk is van de variabele mysql-query_cache_size_MB, standaard ingesteld op 256 Mib. In dat opzicht kan het tot een situatie komen waarin het geheugen gebruikt en u moet bepalen en diagnosticeren of u problemen aantreft binnen uw ProxySQL-knooppunt of zelfs opgemerkt wordt binnen de applicatielaag.
Als je dit identificeert, zou je uiteindelijk de tabellen in de stats_history- en stats-schema's kunnen controleren. U kunt de lijst met tabellen zien die u kunnen helpen tijdens de diagnose,
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)Efficiënt bepalen van de prestaties van uw ProxySQL
Er zijn meerdere manieren om de prestaties van uw ProxySQL-knooppunt te bepalen. Het gebruik van ClusterControl biedt u de mogelijkheid om dit te bepalen met eenvoudige maar duidelijke grafieken. Wanneer ProxySQL bijvoorbeeld is geïntegreerd in uw cluster, kunt u uw queryregels instellen, de max_connections van de gebruiker wijzigen, de topquery's bepalen, een gebruikershostgroep wijzigen en u de prestaties van uw ProxySQL-knooppunt bieden. Zie de screenshots hieronder...
Het enige dat u ziet, is het bewijs van hoe vakkundig ClusterControl u inzicht kan geven in de prestaties van uw ProxySQL-knooppunt. Maar dit beperkt je daar niet toe. ClusterControl heeft ook rijke en krachtige dashboards die we SCUMM noemen, waaronder het ProxySQL-overzichtsdashboard.
Als je van plan bent om langzame zoekopdrachten te bepalen, kun je een blik werpen op het dashboard. Het controleren van uw latentieverdeling over de verschillende hostgroepen waaraan uw backend-knooppunten zijn toegewezen, helpt u om snel inzicht te krijgen in de prestaties op basis van distributie. U kunt de client- en serververbindingen bewaken, op voorwaarde dat u cache-inzichten opvraagt. Het belangrijkste en niet het minste, het geeft u het geheugengebruik dat ProxySQL-knooppunt gebruikt. Zie de grafieken hieronder...
Deze grafieken maken deel uit van het dashboard waarmee u eenvoudig de prestaties van uw ProxySQL-knooppunt.
ClusterControl beperkt u niet bij het omgaan met ProxySQL. Er is hier ook een uitgebreide functie waar je ook een back-up kunt maken of de configuratie kunt importeren, wat erg belangrijk is als je te maken hebt met hoge beschikbaarheid voor je ProxySQL-knooppunten.
Conclusie
Het is nog nooit zo eenvoudig geweest om te controleren en te bepalen of u problemen heeft met uw ProxySQL. Net als in het voorbeeld van deze blog, presenteren we ClusterControl als een tool die u efficiëntie kan bieden en u inzichten kan geven om de openstaande problemen te bepalen waarmee u te maken heeft met uw prestatiegerelateerde problemen.