El error común de MySQL:"Obtuve un error al leer el paquete de comunicación"

MySQL es la segunda base de datos más famosa del mundo según el sitio web DB Engine detrás de Oracle. Lo que hace famoso a MySQL es probablemente porque es un sistema de gestión de bases de datos muy rápido, fiable y flexible. MySQL también es una de las bases de datos admitidas en ClusterControl. Puede implementar, escalar, monitorear y hacer muchas cosas fácilmente con ClusterControl.

Hoy no vamos a hablar de ninguno de ellos, pero discutiremos uno de los errores comunes de MySQL y posibles sugerencias para solucionar problemas. Cuando trabajamos con tickets, muchas veces cuando revisamos los informes o registros de errores, vimos esta línea "Obtuve un error al leer el paquete de comunicación" con bastante frecuencia. Creemos que sería beneficioso si escribimos un blog relacionado con este error no solo para nuestros clientes sino también para otros lectores. ¡No esperemos más, es hora de bucear más!

Protocolo Cliente/Servidor MySQL

Primero que nada, necesitamos entender la forma en que MySQL se comunica entre el cliente y el servidor. Tanto el cliente como el servidor utilizan el protocolo MySQL que se implementa mediante conectores, MySQL Proxy y también la comunicación entre los servidores de replicación maestro y esclavo. El protocolo MySQL admite funciones como el cifrado transparente a través de SSL, la compresión transparente, una fase de conexión y una fase de comando.

Tanto los enteros como las cadenas son los tipos de datos básicos que se utilizan en todo el protocolo MySQL. Siempre que el cliente y el servidor de MySQL deseen comunicarse entre sí o enviar los datos, dividirá los datos en paquetes con un tamaño máximo de 16 MB y también antepondrá un encabezado de paquete a cada fragmento. Dentro de cada paquete, habrá una carga útil que es donde los tipos de datos (enteros/cadenas) juegan su papel.

Considerando que CLIENT_PROTOCOL_41 está habilitado, para casi todos los comandos que el cliente envía al servidor, el servidor responderá cualquiera de los siguientes paquetes como respuesta:

Cómo diagnosticar los problemas

Por lo general, hay dos tipos de problemas de conexión:errores de comunicación o conexiones canceladas. Cada vez que ocurra alguno de estos problemas de conexión, las siguientes fuentes de información son un buen punto de partida para la solución y el análisis de problemas:

• El registro de errores

• El registro general de consultas

• Las variables de estado Aborted_xxx y Connection_errors_xxx

• La memoria caché del host

Errores de conexión y posibles motivos

En caso de que ocurra algún error de conexión y dependiendo de los errores, incrementará el contador de estado para Aborted_clients o Aborted_connects en las variables de estado. Tomado de la documentación de MySQL, Aborted_clients significa la cantidad de conexiones que se cancelaron porque el cliente murió sin cerrar la conexión correctamente. En cuanto a Aborted_connects, significa el número de intentos fallidos de conexión al servidor MySQL.

Si inicia el servidor MySQL con la opción --log-warnings, es probable que vea el ejemplo del siguiente mensaje en su registro de errores. Como notó, el mensaje decía claramente que se relaciona con la conexión abortada, por lo tanto, el contador de estado de Aborted_connects se incrementará en la variable de estado:

[Advertencia] Conexión cancelada 154669 a db:'wordpress' usuario:'wpuser' host:'hostname' (Se produjo un error al leer los paquetes de comunicación)

Normalmente, los intentos de conexión fallidos pueden ocurrir debido a las siguientes razones. Cuando notó esto, posiblemente indica que una persona no autorizada está a punto de violar la base de datos y es posible que desee verlo lo antes posible:

• Un cliente no tiene privilegios para acceder a la base de datos.

• Se ha utilizado una credencial incorrecta.

• Un paquete de conexión que tiene información incorrecta.

• Debido al límite alcanzado para connect_timeout para conectarse.

La variable de estado para Aborted_clients será incrementada por el servidor si un cliente logra conectarse pero se desconecta o finaliza de manera incorrecta. Además de eso, el servidor también registrará un mensaje de conexión cancelada en el registro de errores. Para este tipo de error, comúnmente podría deberse a la siguiente razón:

• El cliente no cierra correctamente la conexión antes de salir (no llama a mysql_close()).

• El cliente ha superado los segundos wait_timeout o interactive_timeout.

• El programa o aplicación cliente finalizó repentinamente en medio de la transferencia de datos.

Además de los motivos anteriores, otros motivos probables de problemas de conexiones anuladas y clientes anulados podrían estar relacionados con cualquiera de los siguientes:

• Configuración TCP/IP desordenada.

• El valor de la variable es demasiado pequeño para max_allowed_packet.

• Asignación de memoria insuficiente para consultas.

• Hardware defectuoso como ethernet, interruptores, cables, etc.

• Problemas con la biblioteca de subprocesos.

• Problema del síndrome dúplex por el que la transferencia se realiza en modo ráfaga-pausa-ráfaga-pausa (si utiliza el protocolo ethernet con Linux, tanto semidúplex como dúplex completo).

Cómo solucionar errores de comunicación de MySQL

Ahora que aprendimos muchas potencialidades que causaron errores de conexión de MySQL. Según nuestra experiencia, la mayoría de las veces este problema está relacionado con el firewall o problemas de red. También es justo decir que no es fácil diagnosticar este tipo de problema. No obstante, la siguiente solución podría serle útil para resolver este error:

• Si su aplicación depende de wait_timeout para cerrar la conexión, vale la pena cambiar la lógica de la aplicación para que sea correctamente cerrado al final de cualquier operación.

• Asegurarse de que el valor de max_allowed_packet esté dentro del rango aceptable para que el cliente no reciba ningún error relacionado con el "paquete demasiado grande".

• Para problemas de demora en la conexión que podrían deberse al DNS, vale la pena verificar si tiene skip-name- resolución habilitada.

• Si está utilizando una aplicación PHP o cualquier otra programación, lo mejor es asegurarse de que no aborte las conexiones que normalmente se establecen en max_execution_time.

• Si notó muchas notificaciones TIME_WAIT de netstat, vale la pena confirmar que las conexiones están bien administradas en el fin de la aplicación.

• Si está utilizando Linux y sospecha que el problema se debe a la red, es mejor verificar la interfaz de red usando el comando ifconfig-a y examine la salida en el servidor MySQL para ver si hay algún error.

• Para los usuarios de ClusterControl, puede habilitar el Registro de auditoría desde Clúster -> Seguridad -> Registro de auditoría. Al habilitar esta función, podría ayudarlo a reducir la búsqueda de la consulta culpable.

• Las herramientas de red como tcpdump y Wireshark podrían ser útiles para identificar posibles problemas de red, tiempos de espera y problemas de recursos para MySQL.

• Revise regularmente el hardware asegurándose de que no haya dispositivos defectuosos, especialmente para ethernets, concentradores, conmutadores, cables etc. Vale la pena reemplazar el aparato defectuoso para asegurarse de que la conexión sea buena todo el tiempo.

Conclusión

Hay muchas razones que podrían conducir a problemas con el paquete de conexión de MySQL. Cada vez que ocurra este problema, definitivamente afectará el negocio y las operaciones diarias. Aunque este tipo de problema no es fácil de diagnosticar y la mayoría de las veces se debe a la red o al firewall, vale la pena tener en cuenta todos los pasos que se han sugerido anteriormente para solucionar el problema. Realmente esperamos que esta publicación de blog pueda ayudarlo de alguna manera, especialmente cuando enfrenta este problema.