En los registros de errores de MySQL, veo estas pocas 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, por lo que me pregunto qué significa esta advertencia, o qué la causa, y si uno podría abordar el problema que los causa. Esto está en RHEL 6.1 y MySQL Enterprise 5.5.
Respuestas:
Uno de los asesinos silenciosos de MySQL Connections es el paquete MySQL.
Primero, descubramos qué es un paquete MySQL.
De acuerdo con la página 99 de "Comprender 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 siempre son razonablemente cortas y, por lo tanto, el servidor puede enviarlas y procesarlas en un fragmento, que se denomina paquete en la terminología de MySQL. El servidor asigna la memoria para un búfer temporal para almacenar el paquete, y solicita lo suficiente para ajustarlo 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, lo que esta opción logra.
El código de interés en relación con 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. Vea sql / field.cc y sql / intem_strfunc.cc para más detalles.
Saber esto acerca de los paquetes MySQL le permite a un desarrollador / DBA dimensionarlos para acomodar múltiples BLOBs dentro de un paquete, incluso si son odiosamente grandes. Definitivamente, un paquete demasiado pequeño causará problemas para las conexiones abiertas a este respecto.
De acuerdo con la 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, supone que algo salió mal con el cliente y cierra la conexión. Si necesita grandes consultas (por ejemplo, si está trabajando con grandes columnas BLOB), puede aumentar el límite de consulta configurando la variable max_allowed_packet del servidor, que tiene un valor predeterminado de 1 MB. Es posible que también necesite aumentar el tamaño máximo de paquete en el extremo del cliente. En la Sección C.5.2.10, “Paquete demasiado grande”, se brinda más información sobre cómo configurar el tamaño del paquete .
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 única solicitud al servidor independientemente del número de filas que se insertarán; por lo tanto, a menudo puede evitar el error reduciendo el número de filas enviadas por INSERT o REPLACE.
RECOMENDACIÓN
Intente elevar max_allowed_packet a un número mucho mayor, ya que el valor predeterminado es 1M. Sugeriría aproximadamente 10 veces el campo TEXTO o BLOB más grande que tenga en su conjunto de datos actual.
Para establecer max_allowed_packet en 256M, puede agregarlo a /etc/my.cnf o my.ini
[mysqld]
max_allowed_packet=256Mpara cubrir futuros reinicios de mysqld. Para instalar el valor ahora en el servidor, ejecute esto:
SET GLOBAL max_allowed_packet = 1024 * 1024 * 256;Darle una oportunidad !!!
Principalmente, por defecto, max_ connections será 100. Intente aumentar el parámetro de configuración
max_ connections = 400, después de configurar en my.cnf reinicie el servidor, o configúrelo dinámicamente:
set @@global.max_connections = 400;Simplemente pruebe la recomendación anterior para evitar estos mensajes de advertencia y también asegúrese de que su red no tenga caídas de paquetes.
Encontré este problema recientemente después de pasar de MySQL Enterprise 5.1.x a 5.7.x , sin cambios significativos 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 que el programa salió con conexiones aún abiertas. La circunstancia de que las conexiones no se cerraron fueron un poco más complicadas y no relacionadas con MySQL sino con ACE, hilos y TSS.