ProxySQL cieszy się obecnie dużym zainteresowaniem w świecie baz danych MySQL i MariaDB, nie wspominając o ClickHouse, który pomaga argumentować za ProxySQL.
Można śmiało powiedzieć, że ProxySQL stał się domyślnym serwerem proxy bazy danych dla rodziny baz danych MySQL (takich jak Percona Server, Oracle MySQL, Galera Cluster, a nawet z MariaDB).
ProxySQL jest w rzeczywistości skutecznym narzędziem do rozwiązywania problemów z niezwykle bogatymi funkcjami, które zarządzają komunikacją klient-serwer bazy danych; działając jako oprogramowanie pośredniczące w bardzo zaawansowanym i wydajnym podejściu.
Umożliwiło to kształtowanie ruchu w bazie danych poprzez opóźnianie, buforowanie lub przepisywanie zapytań w locie. Można go również wykorzystać do stworzenia środowiska, w którym przełączanie awaryjne nie będzie miało wpływu na aplikacje i będzie dla nich niewidoczne. Społeczność ProxySQL jest bardzo responsywna i stale na bieżąco tworzy poprawki, łatki i wydania wersji.
Ale jak wydajna jest twoja konfiguracja ProxySQL i jak możesz ustalić, że twoja konfiguracja została poprawnie dostrojona? Ten blog koncentruje się na określeniu, jak wydajne są Twoje węzły ProxySQL i jak je skutecznie monitorować.
Typowe problemy, które możesz napotkać w ProxySQL
Domyślna instalacja ProxySQL zawiera lekkie, proste narzędzie do dostrajania, które jest w stanie obsłużyć średnie i duże obciążenie. Chociaż może to zależeć od typu zapytań wysyłanych do oprogramowania pośredniego, może to mieć wpływ i zacząć doświadczać wąskich gardeł i opóźnień.
Problemy z opóźnieniami
Na przykład, co może prowadzić do problemów z opóźnieniami, może być trudne do ustalenia, jeśli nie masz systemu monitorowania. Podobnie możesz ręcznie monitorować lub sprawdzać schemat statystyk, tak jak poniżej:
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)Pozwala to monitorować opóźnienia w oparciu o grupę hostów. Ale to dodaje kłopotów, chyba że musisz wprowadzić innowacje i opracować skrypt(y), które zdołają Cię powiadomić.
Błędy połączenia klienta
Maksymalny limit czasu połączenia z powodu maksymalnej liczby połączeń w zapleczu (sam węzeł bazy danych) może prowadzić do zakłopotania, jeśli nie jesteś w stanie określić, co jest głównym źródłem problemu. Możesz jednak sprawdzić bazę danych statystyk, aby sprawdzić przerwane połączenia w kliencie, a nawet na serwerze i odmówiono połączeń w następujący sposób,
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)Jest to również idealne rozwiązanie, jeśli możesz zweryfikować i sprawdzić maksymalną liczbę połączeń użytkownika zaplecza, aby zobaczyć, ile limitów połączeń może on otworzyć lub użyć. Na przykład w moim teście mam następujące elementy:
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)Wolne zapytania
Identyfikacja powolnych zapytań nie może być tak trudna w ProxySQL, ale może być nieefektywna, jeśli zostanie wykonana ręcznie. Możesz to sprawdzić, wykonując ręcznie ze zmienną,
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)Chociaż może to dostarczyć ci pewnych liczb, możesz sprawdzić tabelę stats_mysql_query_digest w schemacie statystyk, jeśli chcesz sięgnąć głębiej. Na przykład poniżej,
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)
który wyłapuje 10 najpopularniejszych powolnych zapytań na podstawie próbkowania 100.
Wykorzystanie pamięci
Elementy sprzętowe, takie jak procesor, dysk i pamięć, muszą być monitorowane, aby zapewnić wydajność serwera ProxySQL. Jednak najważniejsza jest pamięć, ponieważ ProxySQL będzie mocno ją wykorzystywał ze względu na mechanizm pamięci podręcznej zapytań. Domyślnie pamięć podręczna zapytań, która jest zależna od zmiennej mysql-query_cache_size_MB, ma wartość domyślną 256 Mib. W związku z tym może dojść do sytuacji, w której używa pamięci i trzeba określić i zdiagnozować, czy znajdziesz problemy w węźle ProxySQL lub nawet zostaniesz zauważony w warstwie aplikacji.
Identyfikując to, możesz sprawdzić tabele w schematach stats_history i stats. Możesz zobaczyć listę tabel, które mogą Ci pomóc podczas diagnozy,
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)Efektywne określanie wydajności twojego ProxySQL
Istnieje wiele sposobów określenia wydajności węzła ProxySQL. Korzystanie z ClusterControl oferuje możliwość określenia tego za pomocą prostych, ale przejrzystych wykresów. Na przykład, gdy ProxySQL jest zintegrowany z klastrem, będziesz mógł ustawić reguły zapytań, zmienić max_connections użytkownika, określić najlepsze zapytania, zmienić grupę hostów użytkowników i zapewnić wydajność swojego węzła ProxySQL. Zobacz zrzuty ekranu poniżej...
Wszystko, co widzisz, jest dowodem na to, jak sprawnie ClusterControl może zapewnić Ci wgląd w wydajność twojego węzła ProxySQL. Ale to nie ogranicza cię do tego. ClusterControl ma również bogate i wydajne pulpity nawigacyjne, które nazywamy SCUMM, które obejmują pulpit nawigacyjny Przegląd ProxySQL.
Jeśli zamierzasz określić wolne zapytania, możesz po prostu rzucić okiem na pulpit nawigacyjny. Sprawdzanie rozkładu opóźnień w różnych grupach hostów, do których przypisane są węzły zaplecza, pomaga uzyskać szybki wgląd w wydajność w oparciu o dystrybucję. Możesz monitorować połączenia klienta i serwera, zapewniając wgląd w pamięć podręczną zapytań. Co najważniejsze i nie mniej ważne, zapewnia wykorzystanie pamięci, z której korzysta węzeł ProxySQL. Zobacz wykresy poniżej...
Te wykresy są częścią pulpitu nawigacyjnego, który po prostu pomaga łatwo określić wydajność twojego węzła ProxySQL.
ClusterControl nie ogranicza Cię w kontaktach z ProxySQL. Istnieje również bogata funkcja, dzięki której możesz również wykonać kopię zapasową lub zaimportować konfigurację, co jest bardzo ważne, gdy masz do czynienia z wysoką dostępnością swoich węzłów ProxySQL.
Wnioski
Monitorowanie i ustalanie, czy masz jakiekolwiek problemy z serwerem ProxySQL, nigdy nie było prostsze. Podobnie jak w przykładzie z tego bloga, prezentujemy ClusterControl jako narzędzie, które może zapewnić wydajność i dać wgląd w nierozstrzygnięte problemy, które masz do czynienia z problemami związanymi z wydajnością.
