Y nuevamente ERROR 1040 ...
El soporte técnico recibe muchas quejas sobre este notorio error: ERROR 1040: Too many connections , demasiadas conexiones. El problema es obvio: la aplicación o los usuarios crean más conexiones de las que permite el servidor, es decir, el número actual de conexiones excede el valor de la variable max_connections connections.
La situación en sí es un problema para los usuarios finales, pero si aún no tiene acceso al servidor para diagnosticar y corregir la causa, todo se vuelve muy malo. Por lo general, debe completar la instancia y reiniciarla para recuperarla.
¡El usuario root tampoco puede conectarse! ¿Por qué?
En un entorno configurado correctamente, un usuario con el privilegio SUPER podrá acceder a la instancia y diagnosticar la causa del error 1040, debido a que no hay suficientes conexiones. Esto se describe en el manual:
mysqld permite max_connections + 1 conexiones de cliente. Se reserva una conexión adicional para cuentas con privilegios SUPER . Cuando se otorgan estos privilegios a los administradores, y no a los usuarios comunes (que no los necesitan), un administrador que también tiene el privilegio de PROCESS puede conectarse al servidor y usar SHOW PROCESSLIST para diagnosticar problemas, incluso si el número máximo de clientes sin privilegios está conectado.
Pero muchas personas otorgan privilegios SUPER a sus usuarios de la aplicación o script, debido a los requisitos de la aplicación (¡peligroso!) O la falta de conocimiento de las consecuencias, y luego el usuario común ocupa la conexión reservada, y el usuario administrativo (generalmente root ) no puede conectarse.
Cómo garantizar el acceso a una instancia
Puede usar el conocido truco con GDB, que Aurimas aconsejó hace 100 años por el error 1040, pero ahora hay mejores soluciones. Es cierto que primero deben activarse.
Con Percona Server 5.5.29 y superior y MySQL 8.0.14 y superior, puede configurar otro puerto con un número adicional de conexiones. La aplicación no usará estas interfaces. Son solo para administradores de bases de datos y agentes de monitoreo y verificación del estado (ver nota a continuación).
Configurar el servidor Percona
A partir de Percona Server 5.5.29, simplemente puede agregar extra_port a my.cnf , y la próxima vez que reinicie, el puerto estará disponible y esperará datos en el mismo bind_address que las conexiones normales. Si no configura la variable extra_port , no habrá ningún puerto adicional de forma predeterminada.
También puede definir extra_max_connections para especificar el número de conexiones que manejará este puerto. El número predeterminado es 1.
Por ejemplo, tomé todas las conexiones al puerto de usuarios normales desde la instancia donde ya configuré extra_port y extra_max_connections en my.cnf :
resultado
Por cierto, extra_port se eliminó en Percona Server 8.0.14 y superior, porque admin_port con las mismas funciones se implementa en la comunidad MySQL. Edite my.cnf cuando actualice a Percona Server 8.0.14 o superior si ya definió extra_port.
Como dije, esto requiere MySQL 8.0.14, donde se usa WorkLog 12138 .
Para habilitar la interfaz de administrador, debe definir admin_addres , que debe ser el único y único (sin comodines) IPv4, IPv6, dirección asignada de IPv4 o nombre de host en el que la interfaz de administrador esperará a que se transmitan los datos. Si esta variable no está definida, la interfaz no está habilitada.
Todavía puede definir el puerto, pero esto no es necesario. Por defecto, este es el puerto 33062 . Si este puerto está libre, no es necesario configurar este valor. Si configura, coloque ambas variables en la sección [mysqld] en my.cnf .
Finalmente, puede configurar create_admin_listener_thread (deshabilitado por defecto), que crea un hilo separado para manejar las conexiones entrantes. Esto puede ser útil en algunas situaciones.
Otra diferencia es que la documentación de Oracle dice que:
El número de conexiones administrativas es ilimitado.
(Y tenemos el valor predeterminado de 1). No estoy seguro de lo que eso significa, pero tendría cuidado de no establecer accidentalmente 1 millón de conexiones. Ellos, por supuesto, no están limitados, pero aún consumen recursos.
Uso para monitoreo y controles de salud
Convenientemente, no solo las personas pueden usar una interfaz o puerto adicional en caso de emergencia cuando hemos alcanzado max_connections . Se le puede conectar un sistema de monitoreo proxy / balanceador de carga / descubrimiento de servicio.
Las secuencias de comandos de monitoreo podrán recuperar datos para diagramas, de modo que más tarde descubra de dónde provienen tantas conexiones. Y los scripts de comprobación de estado informarán sobre el deterioro del estado del servidor, y cierto código puede indicar que hay muchas conexiones, pero el servidor está administrando (es decir, puede resolverlo y es mejor esperar un poco más antes de que falle).
Asegúrese de instalar solo una conexión a la vez para la supervisión y las comprobaciones de estado, a fin de no obstruir extra_max_ connections en Percona Server y no crear un millón de hilos en MySQL. Es decir, los scripts no deberían volver a conectarse si la solicitud o conexión anterior a la base de datos aún está activa.
Aquí está el mismo ejemplo, pero con MySQL .
Para Percona Server 8.0.14 y superior, el proceso será el mismo que para la comunidad MySQL.
Ayuda! Necesito entrar, ¡pero todos los puertos están ocupados!
Si esta es la razón por la que está leyendo esta publicación, use un truco loco con GDB (sin ofender, Aurimas, simplemente parece arriesgado :-D) o finalice la instancia. Afortunadamente, una instancia casi siempre se puede terminar con SIGTERM (-15) en lugar de SIGKILL (-9). Por lo tanto, el servidor hará una parada limpia y los subprocesos tendrán la oportunidad de apagarse normalmente. Solo sigue las instrucciones:
1) Obtenga el PID:
marcos.albe in ~/ pgrep -x mysqld; 650
2) Enviar SIGTERM a este PID:
marcos.albe in ~/ kill -15 650;
3) Verifique en el registro de errores cómo se realiza el apagado. Se verá más o menos así:
2019-07-11T13:43:28.421244Z 0 [Note] Giving 0 client threads a chance to die gracefully 2019-07-11T13:43:28.521238Z 0 [Note] Shutting down slave threads 2019-07-11T13:43:28.521272Z 0 [Note] Forcefully disconnecting 0 remaining clients
Esto marca el comienzo del proceso de finalización. La instancia se completará cuando vea una línea similar:
2019-07-11T13:43:31.292836Z 0 [Note] /opt/percona_server/5.7.26/bin/mysqld: Shutdown complete