ProxySQL спечели голям интерес в момента в света на базата данни MySQL и MariaDB, да не говорим за ClickHouse, който помага да се оправдае ProxySQL.
Може да се каже, че ProxySQL се превърна в прокси сървър на база данни по подразбиране за семейството бази данни MySQL (като Percona Server, Oracle MySQL, Galera Cluster или дори с MariaDB).
ProxySQL всъщност е ефективно средство за решаване на проблеми с изключително богати функционалности, които управляват комуникацията клиент-сървър база данни; действа като междинен софтуер в много напреднал и производителен подход.
Това направи възможна възможността за оформяне на трафика на базата данни чрез забавяне, кеширане или пренаписване на заявки в движение. Може да се използва и за създаване на среда, в която преминаването на отказ няма да засяга приложенията и ще бъде прозрачно за тях. Общността на ProxySQL е много отзивчива и постоянно изгражда корекции, корекции и версии на версии навреме.
Но колко ефективна е вашата настройка на ProxySQL и как можете да определите дали настройката ви е настроена правилно? Този блог се фокусира върху определянето на ефективността на вашите ProxySQL възли и как да го наблюдавате ефективно.
Чести проблеми, които можете да срещнете с ProxySQL
Инсталацията по подразбиране на ProxySQL идва с лек, прост инструмент за настройка, който е в състояние да се справи със средно до голямо натоварване. Въпреки че това може да зависи от типа на заявките, изпратени към междинния софтуер, това може да повлияе и да започне да изпитва затруднения и забавяне.
Проблеми със закъснението
Например, това, което може да доведе до проблеми със закъснението, може да бъде трудно да се определи, ако нямате система за наблюдение. По същия начин можете ръчно да наблюдавате или проверявате схемата на статистиката, както е по-долу:
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)Това ви позволява да наблюдавате латентността въз основа на хост групата. Но това допълнително увеличава неприятностите, освен ако не се наложи да правите иновации и да разработите скрипт(и), който ще успее да ви уведоми.
Грешки при свързване на клиента
Максималното изчакване на връзката поради максимални връзки в бекенда (самият възел на базата данни) може да ви доведе до недоумение, ако не сте в състояние да определите кой е основният източник на проблема. Можете обаче да проверите базата данни със статистически данни, за да проверите за такива прекъснати връзки в клиента или дори сървъра и са отказани връзки, както следва,
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)Също така е идеално, ако можете да проверите и проверите максималния брой връзки на бекенд потребителя, за да видите какви са ограниченията за свързване, които може да отвори или използва. Например, имам следното в моя тест,
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)Бавни заявки
Идентифицирането на бавните заявки не може да бъде толкова трудно в ProxySQL, но може да бъде неефективно, ако се извършва ръчно. Можете да проверите това, ако правите ръчно с променливата,
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)Въпреки че това може да ви предостави някои цифри, можете да проверите таблицата stats_mysql_query_digest под схемата за статистика, ако искате да копаете по-дълбоко. Например по-долу,
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)
който улавя топ 10 бавни заявки въз основа на извадка от 100.
Използване на паметта
Хардуерните елементи като процесор, диск и памет трябва да бъдат наблюдавани, за да се гарантира, че вашият ProxySQL работи. Въпреки това, най-важното нещо е паметта, тъй като ProxySQL ще използва силно паметта поради механизма за кеширане на заявки. По подразбиране кешът на заявката, който зависи от променливата mysql-query_cache_size_MB, по подразбиране е 256 Mib. В тази връзка може да се стигне до ситуация, в която използва памет и трябва да определите и диагностицирате дали откриете проблеми във вашия ProxySQL възел или дори да бъдете забелязани в слоя на приложението.
Когато идентифицирате това, в крайна сметка може да проверите таблиците в схемите stats_history и stats. Можете да видите списъка с таблици, които могат да ви помогнат по време на диагностиката,
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)Ефективно определяне на производителността на вашия ProxySQL
Има няколко начина за определяне на производителността на вашия ProxySQL възел. Използването на ClusterControl ви предлага възможността да определите това с прости, но ясни графики. Например, когато ProxySQL е интегриран във вашия клъстер, вие ще можете да зададете вашите правила за заявка, да промените max_connections на потребителя, да определите най-добрите заявки, да промените потребителска хост група и да ви предоставим производителността на вашия ProxySQL възел. Вижте екранните снимки по-долу...
Всичко, което виждате, е доказателството за това колко опитно ClusterControl може да ви даде представа за производителността на вашия ProxySQL възел. Но това не ви ограничава до това. ClusterControl също има богати и мощни табла за управление, които наричаме SCUMM, което включва табло за преглед на ProxySQL.
Ако възнамерявате да определяте бавни заявки, можете просто да хвърлите един поглед към таблото за управление. Проверката на вашето разпределение на латентността през различните хост групи, където са назначени вашите бекенд възли, ви помага да имате бърза представа за производителността въз основа на разпределението. Можете да наблюдавате връзките на клиента и сървъра, като ви предоставя информация за кеша на заявки. Най-важното и не на последно място, той ви дава използването на паметта, което ProxySQL възелът използва. Вижте графиките по-долу...
Тези графики са част от таблото за управление, което просто ви помага лесно да определите производителност на вашия ProxySQL възел.
ClusterControl не ви ограничава, когато работите с ProxySQL. Освен това тук има богата функция, където можете също да направите резервно копие или да импортирате конфигурацията, което е много важно, когато имате работа с висока наличност за вашите ProxySQL възли.
Заключение
Никога не е било по-лесно да наблюдавате и да определяте дали имате проблеми с вашия ProxySQL. Както в примера на този блог, ние представяме ClusterControl като инструмент, който може да ви осигури ефективност и да ви даде прозрения, за да определите нерешените проблеми, с които се справяте с проблемите си, свързани с производителността.
