ProxySQL si právě teď získal velký zájem ve světě databází MySQL a MariaDB, nemluvě o ClickHouse, který pomáhá prosazovat ProxySQL.
Je bezpečné říci, že ProxySQL se stal výchozím databázovým proxy pro rodinu databází MySQL (jako je Percona Server, Oracle MySQL, Galera Cluster nebo dokonce s MariaDB).
ProxySQL je ve skutečnosti účinným řešením problémů s extrémně bohatými funkcemi, které řídí komunikaci databáze klient-server; fungující jako middleware ve velmi pokročilém a výkonném přístupu.
Umožnil možnost tvarovat databázový provoz zpožďováním, ukládáním do mezipaměti nebo přepisováním dotazů za běhu. Lze jej také použít k vytvoření prostředí, ve kterém nebude mít převzetí služeb při selhání vliv na aplikace a bude pro ně transparentní. Komunita ProxySQL je velmi pohotová a neustále a včas vytváří opravy, záplaty a vydávání verzí.
Jak výkonné je vaše nastavení ProxySQL a jak zjistíte, že bylo nastavení správně vyladěno? Tento blog se zaměřuje na zjištění, jak výkonné jsou vaše uzly ProxySQL a jak to efektivně monitorovat.
Běžné problémy, se kterými se můžete setkat s ProxySQL
Výchozí instalace proxySQL je dodávána s lehkým a jednoduchým nástrojem pro ladění, který je schopen zvládnout průměrné až velké zatížení. Ačkoli to může záviset na typu dotazů odesílaných do middlewaru, může to ovlivnit a začít se objevovat úzká místa a latence.
Problémy s latencí
Pokud například nemáte monitorovací systém, může být obtížné určit, co může vést k problémům s latencí. Podobně můžete ručně sledovat nebo kontrolovat statistické schéma, jak je uvedeno níže:
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)To vám umožňuje sledovat latenci na základě hostitelské skupiny. Ale přidává to potíže, pokud nemusíte inovovat a vyvíjet skript(y), které vás budou upozorňovat.
Chyby připojení klienta
Maximální časový limit připojení kvůli maximálnímu počtu připojení v backendu (samotný databázový uzel) vás může vést ke zmatku, pokud nejste schopni určit, co je hlavním zdrojem problému. Můžete však zkontrolovat databázi statistik a zkontrolovat taková přerušená připojení na klientovi nebo dokonce na serveru a jeho připojení jsou odepřena následovně,
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)Je také ideální, pokud můžete ověřit a zkontrolovat maximální počet připojení koncového uživatele, abyste viděli, jaký je počet limitů připojení, které může otevřít nebo použít. Ve svém testu mám například následující,
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)Pomalé dotazy
Identifikace pomalých dotazů nemůže být v ProxySQL tak obtížná, ale může být neefektivní, pokud se provádí ručně. Můžete to zkontrolovat, pokud děláte manuál s proměnnou,
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)I když vám to může poskytnout nějaká čísla, můžete se podívat do tabulky stats_mysql_query_digest pod schématem statistik, pokud se chcete ponořit hlouběji. Například níže,
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)
který zachycuje 10 nejpomalejších dotazů na základě vzorkování 100.
Využití paměti
Hardwarové položky, jako je CPU, Disk a Paměť, musí být monitorovány, aby bylo zajištěno, že vaše ProxySQL je výkonné. Nejdůležitější věcí je však paměť, protože ProxySQL bude hojně využívat paměť kvůli mechanismu mezipaměti dotazů. Ve výchozím nastavení je mezipaměť dotazů, která je závislá na proměnné mysql-query_cache_size_MB, výchozí 256 Mib. V tomto ohledu může dojít k situaci, kdy používá paměť a vy potřebujete určit a diagnostikovat, pokud najdete problémy ve svém uzlu ProxySQL nebo si jich dokonce všimnete v aplikační vrstvě.
Při identifikaci toho můžete skončit kontrolou tabulek ve stats_history a statistických schématech. Můžete vidět seznam tabulek, které vám mohou pomoci při diagnostice,
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)Efektivní určování výkonu vašeho ProxySQL
Existuje několik způsobů, jak určit výkon vašeho uzlu ProxySQL. Použití ClusterControl vám nabízí možnost určit to pomocí jednoduchých, ale přímočarých grafů. Když je například ProxySQL integrován do vašeho clusteru, budete moci nastavit pravidla dotazů, změnit max_connections uživatele, určit nejčastější dotazy, změnit skupinu hostitelů uživatelů a poskytnout vám výkon vašeho uzlu ProxySQL. Podívejte se na snímky obrazovky níže...
Vše, co vidíte, je důkaz toho, jak zdatně vám může ClusterControl poskytnout přehled výkon vašeho uzlu ProxySQL. Ale to vás neomezuje. ClusterControl má také bohaté a výkonné řídicí panely, které nazýváme SCUMM, které zahrnují řídicí panel ProxySQL Overview.
Pokud chcete určit pomalé dotazy, můžete se jednoduše podívat na řídicí panel. Kontrola distribuce latence v různých hostitelských skupinách, ke kterým jsou přiřazeny vaše backendové uzly, vám pomůže získat rychlý přehled o výkonu na základě distribuce. Můžete monitorovat připojení klienta a serveru a poskytovat vám přehledy mezipaměti dotazů. A co je nejdůležitější a v neposlední řadě, poskytuje vám využití paměti, které uzel ProxySQL používá. Viz grafy níže...
Tyto grafy jsou součástí řídicího panelu, který vám jednoduše pomůže snadno určit výkon vašeho uzlu ProxySQL.
ClusterControl vás neomezuje při práci s ProxySQL. Také je zde bohatá funkce, kde můžete také zálohovat nebo importovat konfiguraci, což je velmi důležité, když se zabýváte vysokou dostupností pro vaše uzly ProxySQL.
Závěr
Nikdy nebylo snazší sledovat a zjišťovat, zda máte nějaké problémy s vaším ProxySQL. Stejně jako v příkladu tohoto blogu představujeme ClusterControl jako nástroj, který vám může poskytnout efektivitu a poskytnout vám přehled, abyste mohli určit nevyřešené problémy, které řešíte s problémy souvisejícími s výkonem.