Uno de los asesinos silenciosos de MySQL Connections es el paquete MySQL. Incluso el hilo de E / S de la replicación MySQL puede ser víctima de esto.
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. También es posible que deba 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 INSERTAR o REEMPLAZAR.
Por lo menos, debe asegurarse de que los tamaños de los paquetes tanto para la máquina de la que mysqldump'd como para la máquina que está cargando sean idénticos.
Puede haber dos (2) enfoques que puede tomar:
ENFOQUE # 1: Realice mysqldump usando --skip-extended-insert
Esto asegurará que el paquete MySQL no esté inundado con múltiples BLOBs, campos TEXT. De esa manera, los INSERTOS SQL se realizan uno por uno. Los principales inconvenientes son
- el mysqldump es mucho más grande
- Recargar un vertedero de este tipo lleva mucho más tiempo.
ENFOQUE # 2: Incrementar max_allowed_packet
Este puede ser el enfoque preferido porque implementar esto es solo un reinicio de mysql. Comprender qué es el paquete MySQL puede aclarar esto.
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 lo explican:
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.
Dada esta explicación, hacer INSERTs masivos cargará / descargará un paquete MySQL con bastante rapidez. Esto es especialmente cierto cuando max_allowed_packet es demasiado pequeño para la carga de datos dada que llega a él.
CONCLUSIÓN
En la mayoría de las instalaciones de MySQL, generalmente configuro esto en 256M o 512M. Debería experimentar con valores mayores cuando las cargas de datos producen errores de "MySQL se ha ido".
max_allowed_packeten 900M y estaba usando--skip-extended-insert(y tiene razón, eso hace que db-dumps huuuge), pero todavía falla. Sospecho que hay una línea particular en el basurero ahora que probablemente puedo evitar. Pero sigue siendo extraño: el volcado se puede importar bien en mi servidor CentOS.