O ProxySQL ganhou muito interesse agora no mundo dos bancos de dados MySQL e MariaDB, sem mencionar o ClickHouse, que ajuda a defender o ProxySQL.
É seguro dizer que o ProxySQL se tornou o proxy de banco de dados padrão para a família de bancos de dados MySQL (como Percona Server, Oracle MySQL, Galera Cluster ou mesmo com MariaDB).
ProxySQL é, de fato, um solucionador de problemas eficiente com funcionalidades extremamente ricas que gerenciam a comunicação cliente-servidor do banco de dados; atuando como o middleware em uma abordagem muito avançada e de alto desempenho.
Tornou possível a capacidade de moldar o tráfego do banco de dados atrasando, armazenando em cache ou reescrevendo consultas em tempo real. Ele também pode ser usado para criar um ambiente no qual os failovers não afetarão os aplicativos e serão transparentes para eles. A comunidade ProxySQL é muito responsiva e constantemente cria correções, patches e lançamentos de versão em tempo hábil.
Mas qual é o desempenho de sua configuração do ProxySQL e como você pode determinar que sua configuração foi ajustada corretamente? Este blog se concentra em determinar o desempenho de seus nós ProxySQL e como monitorá-los com eficiência.
Problemas comuns que você pode encontrar com o ProxySQL
A instalação padrão do ProxySQL vem com uma ferramenta de ajuste simples e leve, capaz de lidar com cargas médias a pesadas. Embora isso possa depender do tipo de consultas enviadas ao middleware, pode afetar e começar a experimentar gargalos e latência.
Problemas de latência
Por exemplo, o que pode levar a problemas de latência pode ser difícil de determinar se você não tiver um sistema de monitoramento. Da mesma forma, você pode monitorar manualmente ou verificar o esquema de estatísticas como abaixo:
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)Isso permite monitorar a latência com base no hostgroup. Mas aumenta o incômodo, a menos que você tenha que inovar e desenvolver um script que consiga notificá-lo.
Erros de conexão do cliente
O tempo limite máximo de conexão devido ao máximo de conexões no backend (o próprio nó do banco de dados) pode causar perplexidade se você não conseguir determinar qual é a principal fonte do problema. Você pode verificar o banco de dados de estatísticas para verificar essas conexões abortadas no cliente ou mesmo no servidor e as conexões negadas da seguinte forma,
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)Também é ideal se você puder verificar e verificar o número máximo de conexões do usuário backend para ver qual é o número de limites de conexão que ele pode abrir ou usar. Por exemplo, eu tenho o seguinte no meu teste,
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)Consultas lentas
Identificar as consultas lentas não pode ser tão difícil no ProxySQL, mas pode ser ineficiente se feito manualmente. Você pode verificar isso se estiver fazendo manual com a variável,
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)Embora isso possa fornecer alguns números, você pode verificar a tabela stats_mysql_query_digest no esquema de estatísticas se quiser se aprofundar. Por exemplo abaixo,
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)
que captura as 10 principais consultas lentas com base em uma amostragem por 100.
Utilização da memória
Itens de hardware como CPU, Disco e Memória precisam ser monitorados para garantir que seu ProxySQL esteja funcionando. No entanto, o mais importante é a memória, pois o ProxySQL utilizará muito a memória devido ao mecanismo de cache de consulta. Por padrão, o cache de consulta, que depende da variável mysql-query_cache_size_MB, é padronizado para 256 Mib. Nesse sentido, pode chegar a uma situação em que ele usa memória e você precisa determinar e diagnosticar se encontrar problemas em seu nó ProxySQL ou até mesmo ser notado na camada do aplicativo.
Ao identificar isso, você pode acabar verificando as tabelas nos esquemas stats_history e stats. Você pode ver a lista de tabelas que podem ajudá-lo durante o diagnóstico,
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)Determinando com eficiência o desempenho do seu ProxySQL
Existem várias maneiras de determinar o desempenho de seu nó ProxySQL. O uso do ClusterControl oferece a capacidade de determinar isso com gráficos simples, mas diretos. Por exemplo, quando o ProxySQL estiver integrado ao seu cluster, você poderá definir suas regras de consulta, alterar max_connections do usuário, determinar as principais consultas, alterar um grupo de hosts de usuário e fornecer o desempenho do seu nó ProxySQL. Veja as capturas de tela abaixo...
Tudo o que você vê é a prova de quão proficiente o ClusterControl pode fornecer informações sobre o desempenho do seu nó ProxySQL. Mas isso não o limita a isso. O ClusterControl também possui painéis ricos e poderosos que chamamos de SCUMM, que incluem o painel de visão geral do ProxySQL.
Se você pretende determinar consultas lentas, basta dar uma olhada no painel. Verificar sua distribuição de latência nos diferentes grupos de hosts onde seus nós de back-end são atribuídos ajuda você a ter uma visão rápida do desempenho com base na distribuição. Você pode monitorar as conexões do cliente e do servidor, fornecendo informações sobre o cache de consulta. Mais importante e não menos importante, ele fornece a utilização de memória que o nó ProxySQL está usando. Veja os gráficos abaixo...
Esses gráficos fazem parte do painel que simplesmente ajuda você a determinar facilmente o desempenho do seu nó ProxySQL.
ClusterControl não limita você ao lidar com ProxySQL. Além disso, há um recurso rico aqui onde você também pode fazer um backup ou importar a configuração que é muito importante quando você está lidando com alta disponibilidade para seus nós ProxySQL.
Conclusão
Nunca foi tão fácil monitorar e determinar se você tem algum problema com seu ProxySQL. Como no exemplo deste blog, estamos apresentando o ClusterControl como uma ferramenta que pode fornecer eficiência e fornecer insights para determinar os problemas pendentes com os quais você está lidando com seus problemas relacionados ao desempenho.
