Tener un equilibrador de carga o un proxy inverso frente a su servidor MySQL o MariaDB agrega un poco de complejidad a la configuración de su base de datos, lo que puede llevar a que algunas cosas se comporten de manera diferente. Teóricamente, un equilibrador de carga que se encuentra frente a los servidores MySQL (por ejemplo, un HAProxy frente a un Galera Cluster) debería actuar como un administrador de conexión y distribuir las conexiones a los servidores back-end de acuerdo con algún algoritmo de equilibrio. MySQL, por otro lado, tiene su propia forma de administrar las conexiones de los clientes. Idealmente, necesitaríamos configurar estos dos componentes juntos para evitar comportamientos inesperados y reducir la superficie de solución de problemas al depurar problemas.
Si tiene esa configuración, es importante comprender estos componentes, ya que pueden afectar el rendimiento general de su servicio de base de datos. En esta entrada de blog, nos sumergiremos en las max_connections de MySQL. y HAProxy maxconn opciones respectivamente. Tenga en cuenta que el tiempo de espera es otro parámetro importante que debemos saber, pero lo cubriremos en una publicación separada.
Conexiones máximas de MySQL
Recursos relacionados Equilibrio de carga de MySQL con HAProxy - Tutorial Reproducción del seminario web y preguntas y respuestas:cómo implementar y administrar ProxySQL, HAProxy y MaxScale Reproducción y diapositivas del seminario web:Cómo crear infraestructuras de bases de datos escalables con MariaDB y HAProxyEl número de conexiones permitidas a un servidor MySQL está controlado por max_connections variable del sistema. El valor predeterminado es 151 (MySQL 5.7).
Para determinar un buen número para max_connections , las fórmulas básicas son:
donde,
**Variable innodb_additional_mem_pool_size se elimina en MySQL 5.7.4+. Si está ejecutando la versión anterior, tenga en cuenta esta variable.
Y,
Usando las fórmulas anteriores, podemos calcular un max_connections adecuado valor para este servidor MySQL en particular. Para iniciar el proceso, detenga todas las conexiones de los clientes y reinicie el servidor MySQL. Asegúrese de tener solo la cantidad mínima de procesos ejecutándose en ese momento en particular. Puede usar 'mysqladmin' o 'MOSTRAR LISTA DE PROCESOS' para este propósito:
$ mysqladmin -uroot -p processlist
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| 232172 | root | localhost | NULL | Query | 0 | NULL | show processlist | 0.000 |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
1 row in set (0.00 sec)Del resultado anterior, podemos decir que solo un usuario está conectado al servidor MySQL, que es root. Luego, recupere la RAM disponible (en MB) del host (busque en la columna 'disponible'):
$ free -m
total used free shared buff/cache available
Mem: 3778 1427 508 148 1842 1928
Swap: 2047 4 2043Solo como información, la columna 'disponible' brinda una estimación de cuánta memoria está disponible para iniciar nuevas aplicaciones, sin intercambio (solo disponible en kernel 3.14+).
Luego, especifique la memoria disponible, 1928 MB en la siguiente declaración:
mysql> SELECT ROUND((1928 - (ROUND((@@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@query_cache_size + @@tmp_table_size + @@key_buffer_size) / 1024 / 1024))) / (ROUND(@@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size + @@thread_stack + @@join_buffer_size + @@binlog_cache_size) / 1024 / 1024)) AS 'Possible Max Connections';
+--------------------------+
| Possible Max Connections |
+--------------------------+
| 265 |
+--------------------------+**Variable innodb_additional_mem_pool_size se elimina en MySQL 5.7.4+. Si está ejecutando la versión anterior, tenga en cuenta esta variable.
A partir de este ejemplo, podemos tener hasta 265 conexiones MySQL simultáneamente según la memoria RAM disponible que tenga el host. No tiene sentido configurar un valor más alto que ese. Luego, agregue la siguiente línea dentro del archivo de configuración de MySQL, bajo la directiva [mysqld]:
max_connections = 265Reinicie el servicio MySQL para aplicar el cambio. Cuando el total de conexiones simultáneas llegue a 265, obtendrá un error de "Demasiadas conexiones" al intentar conectarse al servidor mysqld. Esto significa que todas las conexiones disponibles están siendo utilizadas por otros clientes. MySQL realmente permite max_connections +1 clientes para conectarse. La conexión extra está reservada para uso de cuentas que tienen el privilegio SUPER. Entonces, si se encuentra con este error, debe intentar acceder al servidor como usuario raíz (o cualquier otro usuario SUPER) y consultar la lista de procesos para iniciar la solución de problemas.
Conexiones máximas de HAProxy
HAProxy tiene 3 tipos de conexiones máximas (maxconn):global, predeterminado/escucha y servidor predeterminado. Supongamos que una instancia de HAProxy está configurada con dos escuchas, una para escuchar con varios escritores en el puerto 3307 (las conexiones se distribuyen a todos los servidores backend de MySQL) y otra es de un solo escritor en el puerto 3308 (las conexiones se reenvían a un solo servidor de MySQL):
global
...
maxconn 2000 #[a]
...
defaults
...
maxconn 3 #[b]
...
listen mysql_3307
...
maxconn 8 #[c]
balance leastconn
default-server port 9200 maxqueue 10 weight 10 maxconn 4 #[d]
server db1 192.168.55.171 check
server db2 192.168.55.172 check
server db3 192.168.55.173 check
listen mysql_3308
...
default-server port 9200 maxqueue 10 weight 10 maxconn 5 #[e]
server db1 192.168.55.171 check
server db2 192.168.55.172 check backup #[f]Veamos el significado de algunas de las líneas de configuración:
global.maxconn [a]
El número total de conexiones simultáneas que pueden conectarse a esta instancia de HAProxy. Por lo general, este valor es el valor más alto de todos. En este caso, HAProxy aceptará un máximo de 2000 conexiones a la vez y las distribuirá a todos los oyentes definidos en el proceso HAProxy o trabajador (puede ejecutar múltiples procesos HAProxy usando nbproc opción).
HAProxy dejará de aceptar conexiones cuando se alcance este límite. El parámetro "ulimit-n" se ajusta automáticamente a este valor. Dado que los sockets se consideran equivalentes a los archivos desde la perspectiva del sistema, el límite predeterminado de descriptores de archivos es bastante pequeño. Probablemente desee aumentar el límite predeterminado ajustando el núcleo para los descriptores de archivos.
predeterminados.maxconn [b]
Valor predeterminado de conexiones máximas para todos los oyentes. No tiene sentido si este valor es mayor que global.maxconn .
Si falta la línea "maxconn" debajo de la estrofa "escuchar" (listen.maxconn ), el oyente obedecerá este valor. En este caso, el oyente mysql_3308 obtendrá un máximo de 3 conexiones a la vez. Para estar seguro, establezca este valor igual a global.maxconn , dividido por el número de oyentes. Sin embargo, si desea priorizar a otros oyentes para tener más conexiones, use listen.maxconn en su lugar.
escuchar.maxconn [c]
Las conexiones máximas permitidas para el oyente correspondiente. El oyente tiene prioridad sobre defaults.maxconn si se especifica. No tiene sentido si este valor es mayor que global.maxconn .
Para una distribución justa de las conexiones a los servidores backend, como en el caso de un escucha de múltiples escritores (mysql_3307), establezca este valor como listen.default-server.maxconn multiplicar por el número de servidores backend. En este ejemplo, un mejor valor debería ser 12 en lugar de 8 [c]. Si optamos por mantener esta configuración, se espera que db1 y db2 reciban un máximo de 3 conexiones cada uno, mientras que db3 recibirá un máximo de 2 conexiones (debido al balance de conexiones mínimo), lo que equivale a 8 conexiones en total. No alcanzará el límite especificado en [d].
Para el escucha de un solo escritor (mysql_3308) donde las conexiones deben asignarse a un único servidor back-end a la vez, establezca este valor para que sea igual o mayor que listen.default-server.maxconn .
escuchar.servidor-predeterminado.maxconn [d][e]
Este es el número máximo de conexiones que cada servidor backend puede recibir a la vez. No tiene sentido si este valor es mayor que listen.maxconn o predeterminados.maxconn . Este valor debe ser inferior o igual a max_connections de MySQL. variable. De lo contrario, corre el riesgo de agotar las conexiones con el servidor back-end de MySQL, especialmente cuando las variables de tiempo de espera de MySQL están configuradas por debajo de los tiempos de espera de HAProxy.
En este ejemplo, configuramos cada servidor MySQL para obtener solo un máximo de 4 conexiones a la vez para los nodos Galera de múltiples escritores [d]. Mientras que el nodo Galera de un solo escritor obtendrá un máximo de 3 conexiones a la vez, debido al límite que se aplica desde [b]. Dado que especificamos "copia de seguridad" [f] en el otro nodo, el nodo activo obtendrá de inmediato las 3 conexiones asignadas a este oyente.
La explicación anterior se puede ilustrar en el siguiente diagrama:
Para resumir la distribución de conexiones, se espera que db1 obtenga un número máximo de 6 conexiones (3 de 3307 + 3 de 3308). db2 obtendrá 3 conexiones (a menos que db1 se caiga, donde obtendrá 3 adicionales) y db3 se mantendrá en 2 conexiones independientemente de los cambios de topología en el clúster.
Monitoreo de conexión con ClusterControl
Con ClusterControl, puede monitorear el uso de la conexión MySQL y HAProxy desde la interfaz de usuario. La siguiente captura de pantalla proporciona un resumen del asesor de conexión MySQL (ClusterControl -> Rendimiento -> Asesores) donde monitorea las conexiones MySQL actuales y las que se han usado alguna vez para cada servidor en el clúster:
Para HAProxy, ClusterControl se integra con la página de estadísticas de HAProxy para recopilar métricas. Estos se presentan en la pestaña Nodos:
A partir de la captura de pantalla anterior, podemos decir que cada servidor backend en el oyente de múltiples escritores obtiene un máximo de 8 conexiones. Se están ejecutando 4 sesiones simultáneas. Estos están resaltados en el cuadrado rojo superior, mientras que el oyente de un solo escritor sirve 2 conexiones y las reenvía a un solo nodo respectivamente.
Conclusión
Es importante configurar las conexiones máximas para el servidor HAProxy y MySQL para garantizar una buena distribución de la carga a nuestros servidores de bases de datos y proteger los servidores MySQL de la sobrecarga o el agotamiento de sus conexiones.
