ProxySQL ha ganado mucho interés en este momento en el mundo de las bases de datos MySQL y MariaDB, sin mencionar ClickHouse, que ayuda a defender ProxySQL.
Es seguro decir que ProxySQL se ha convertido en el proxy de base de datos predeterminado para la familia de bases de datos MySQL (como Percona Server, Oracle MySQL, Galera Cluster o incluso con MariaDB).
ProxySQL es, de hecho, un solucionador de problemas eficiente con funcionalidades extremadamente ricas que administran la comunicación cliente-servidor de la base de datos; actuando como el middleware en un enfoque muy avanzado y eficaz.
Ha hecho posible la capacidad de dar forma al tráfico de la base de datos retrasando, almacenando en caché o reescribiendo consultas sobre la marcha. También se puede utilizar para crear un entorno en el que las conmutaciones por error no afectarán a las aplicaciones y serán transparentes para ellas. La comunidad de ProxySQL es muy receptiva y crea constantemente correcciones, parches y lanzamientos de versiones de manera oportuna.
Pero, ¿cuál es el rendimiento de su configuración de ProxySQL y cómo puede determinar que su configuración se ha ajustado correctamente? Este blog se enfoca en determinar el rendimiento de sus nodos ProxySQL y cómo monitorearlos de manera eficiente.
Problemas comunes que puede encontrar con ProxySQL
La instalación predeterminada de ProxySQL viene con una herramienta de ajuste simple y liviana que puede manejar cargas promedio a pesadas. Aunque esto puede depender del tipo de consultas enviadas al middleware, puede afectar y comenzar a experimentar cuellos de botella y latencia.
Problemas de latencia
Por ejemplo, lo que puede conducir a problemas de latencia puede ser difícil de determinar si no cuenta con un sistema de monitoreo. Del mismo modo, puede monitorear o verificar manualmente el esquema de estadísticas como se muestra a continuación:
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)Esto le permite monitorear la latencia según el grupo de host. Pero se suma la molestia a menos que tenga que innovar y desarrollar un script (s) que logre notificarle.
Errores de conexión del cliente
El tiempo de espera máximo de conexión debido a las conexiones máximas en el backend (nodo de la base de datos en sí) puede dejarlo perplejo si no puede determinar cuál es la fuente principal del problema. Sin embargo, puede consultar la base de datos de estadísticas para verificar tales conexiones abortadas en el cliente o incluso en el servidor y se niegan las conexiones de la siguiente manera,
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)También es ideal si puede verificar y verificar la cantidad máxima de conexiones del usuario backend para ver cuál es la cantidad de límites de conexión que puede abrir o usar. Por ejemplo, tengo lo siguiente en mi prueba,
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 las consultas lentas no puede ser tan difícil en ProxySQL, pero puede ser ineficiente si se hace manualmente. Puede verificar esto si está haciendo manual con la variable,
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)Si bien eso puede proporcionarle algunos números, puede consultar la tabla stats_mysql_query_digest en el esquema de estadísticas si desea profundizar más. Por ejemplo a continuación,
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 detecta las 10 consultas más lentas según un muestreo de 100.
Uso de memoria
Los elementos de hardware como la CPU, el disco y la memoria deben monitorearse para garantizar que su ProxySQL funcione. Sin embargo, lo más importante es la memoria, ya que ProxySQL utilizará mucho la memoria debido al mecanismo de caché de consultas. De forma predeterminada, la caché de consultas, que depende de la variable mysql-query_cache_size_MB, tiene un valor predeterminado de 256 Mib. En ese sentido, puede llegar a una situación en la que use memoria y necesite determinar y diagnosticar si encuentra problemas dentro de su nodo ProxySQL o incluso si se nota dentro de la capa de aplicación.
Al identificar esto, es posible que termine revisando las tablas en los esquemas stats_history y stats. Puede ver la lista de tablas que pueden ayudarlo durante el 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)Determinación eficiente del rendimiento de su ProxySQL
Hay varias formas de determinar el rendimiento de su nodo ProxySQL. El uso de ClusterControl le ofrece la posibilidad de determinar esto con gráficos simples pero directos. Por ejemplo, cuando ProxySQL está integrado en su clúster, podrá establecer sus reglas de consulta, cambiar las conexiones máximas de los usuarios, determinar las consultas principales, cambiar un grupo de host de usuarios y proporcionarle el rendimiento de su nodo ProxySQL. Vea las capturas de pantalla a continuación...
Todo lo que ve es la prueba de la eficacia con la que ClusterControl puede brindarle información sobre el rendimiento de su nodo ProxySQL. Pero esto no te limita a eso. ClusterControl también tiene paneles completos y potentes que llamamos SCUMM, que incluye el panel de información general de ProxySQL.
Si tiene la intención de determinar consultas lentas, simplemente puede echar un vistazo al tablero. Verificar su distribución de latencia en los diferentes grupos de host donde se asignan sus nodos de back-end lo ayuda a tener una idea rápida del rendimiento según la distribución. Puede monitorear las conexiones del cliente y del servidor, brindándole información sobre la caché de consultas. Lo más importante y no menos importante, le brinda la utilización de memoria que está utilizando el nodo ProxySQL. Vea los gráficos a continuación...
Estos gráficos son parte del tablero que simplemente lo ayuda a determinar fácilmente el rendimiento de su nodo ProxySQL.
ClusterControl no lo limita cuando se trata de ProxySQL. Además, aquí hay una característica rica en la que también puede realizar una copia de seguridad o importar la configuración, lo cual es muy importante cuando se trata de alta disponibilidad para sus nodos ProxySQL.
Conclusión
Nunca ha sido tan fácil monitorear y determinar si tiene algún problema con su ProxySQL. Como en el ejemplo de este blog, estamos mostrando ClusterControl como una herramienta que puede brindarle eficiencia y brindarle información para determinar los problemas pendientes que está enfrentando con sus problemas relacionados con el rendimiento.
