En los registros de errores de MySQL, veo algunas advertencias como estas:

120611 16:12:30 [Warning] Aborted connection 2619503 to db: "db_name" user: "user_name" host: "webapp_hostname" (Got an error reading communication packets) 

No he notado ninguna pérdida de datos per se, así que me pregunto qué significa esta advertencia, o qué la causa, y si se puede abordar el problema que los causa. Esto es en RHEL 6.1 y MySQL Enterprise 5.5.

Respuesta

Uno de los asesinos silenciosos de MySQL Connections es el paquete MySQL.

Primero, averigüemos qué es un paquete MySQL.

De acuerdo con la página 99 de «Comprensión de los componentes internos de MySQL» (ISBN 0-596-00957 -7) , aquí están los párrafos 1-3 que explican los paquetes MySQL:

El código de comunicación de red MySQL se escribió bajo el supuesto de que las consultas son siempre razonablemente corto y, por lo tanto, puede ser enviado y procesado por el servidor en un solo fragmento, que se denomina paquete en terminología MySQL. El servidor asigna la memoria a un búfer temporal para almacenar el paquete y solicita lo suficiente para que quepa en él por completo. Esta arquitectura requiere una precaución para evitar que el servidor se quede sin memoria — un límite en el tamaño del paquete, que esta opción logra.

El código de interés en relación a esta opción se encuentra en sql / net_serv.cc . Eche un vistazo a my_net_read () , luego siga la llamada a my_real_read () y preste especial atención a net_realloc () .

Esta variable también limita la longitud de un resultado de muchas funciones de cadena. Consulte sql / field.cc y sql / intem_strfunc.cc para obtener más detalles.

Saber esto sobre los paquetes MySQL permite a un desarrollador / administrador de base de datos ajustar su tamaño para acomodar múltiples BLOB dentro de un paquete incluso si son desagradablemente grandes. Definitivamente, un paquete demasiado pequeño causará problemas para las conexiones abiertas a este respecto.

De acuerdo con Documentación de MySQL

  • También puede obtener estos errores si envía una consulta al servidor que es incorrecta o demasiado grande. Si mysqld recibe un paquete que es demasiado grande o está fuera de servicio, asume que algo salió mal con el cliente y cierra la conexión. Si necesita consultas grandes (por ejemplo, si está trabajando con columnas BLOB grandes), puede aumentar el límite de consultas configurando la variable max_allowed_packet del servidor, que tiene un valor predeterminado de 1 MB. Es posible que también deba aumentar el tamaño del paquete en el extremo del cliente. Se proporciona más información sobre cómo configurar el tamaño del paquete en la Sección C.5.2.10, “Paquete demasiado grande”.

  • Una instrucción INSERT o REPLACE que inserta una gran cantidad de filas también puede causar este tipo de errores. Cualquiera de estas declaraciones envía una sola solicitud al servidor independientemente del número de filas que se inserten ; por lo tanto, a menudo puede evitar el error reduciendo el número de filas enviadas por INSERT o REPLACE.

RECOMENDACIÓN

Intente aumentar el max_allowed_packet a un número mucho mayor, ya que el valor predeterminado es 1M. Sugeriría aproximadamente 10 veces el campo de TEXTO o BLOB más grande que tiene en su conjunto de datos actual.

Para configurar max_allowed_packet en 256M, puede agregarlo a /etc/my.cnf o my.ini

[mysqld] max_allowed_packet=256M 

para cubrir futuros reinicios de mysqld. Para instalar el valor ahora en el servidor, ejecute esto:

SET GLOBAL max_allowed_packet = 1024 * 1024 * 256; 

¡Pruébelo!

Comentarios

  • Muy buena explicación.
  • @RolandoMySQLDBA Sigo recibiendo el error en 5.7.28 después de probar todas las soluciones mencionadas. Cualquier consejo para solucionar más problemas

Respuesta

La mayoría de las conexiones máximas predeterminadas serán 100. Intente aumentar el parámetro de configuración

max_connections = 400, después de configurar my.cnf reinicie el servidor, o configúrelo dinámicamente:

 set @@global.max_connections = 400; 

Simplemente pruebe la recomendación anterior para evite estos mensajes de advertencia y también asegúrese de que su red no tenga pérdidas de paquetes.

Respuesta

Encontré este problema recientemente después de mudarme MySQL Enterprise 5.1.x a 5.7.x , sin ningún cambio significativo en el código de la aplicación, la « nota » comenzó a aparecer.

En mi caso, la causa raíz de la aparición de la « nota » fue el programa saliendo con conexiones aún abiertas.La circunstancia de que las conexiones no se cerraran fueron un poco más complicadas y no relacionadas con MySQL sino con ACE, subprocesos y TSS.

Respuesta

No mencionado aquí, así que incluyo otra causa de este problema. En mi caso, mientras usaba el cliente de línea de comandos mysql, el error fue causado por un valor bajo de 30 segundos de interactive_timeout:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout
Esto persistirá en las sesiones, pero no se reiniciará el servidor.

SET GLOBAL interactive_timeout=6000; 

Respuesta

Me encontré con el mismo problema con MariaDB 10.3.24. Parece que la Advertencia puede ocurrir por todas las razones anteriores y algunas más. En mi caso, se debió a un registro en una de las tablas de la base de datos que tenía un valor de diccionario vacío para uno de los campos.

+ —- + ——– + | id | config | + —- + ——– + | 3 | {} | + —- + ——– +

Como prueba cambié «{}» a «()» y eso detuvo el mensaje. En caso de que ayude a alguien.

Responder

Esta línea my.ini resolvió mi problema:

log_error_verbosity=1 

Consulte este enlace

Comentarios

  • No ' no creo que hayas resuelto el problema subyacente, sino que simplemente dejaste de registrarlo.
  • Estaba recibiendo el mismo mensaje reportado como " Nota ". El uso de log_error_verbosity = 2 en realidad resuelve el " problema " (pero una " Advertencia " debe abordarse, no ignorarse)

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *