Este error tan inusual me tocó con un servidor en producción, que aparentemente había presentado varios problemas por una falla de electricidad. La tarjeta madre sufrió la peor parte y entonces presentaba fallos con el procesador y con la memoria. Para traspasar la de base de datos a otro servidor necesitaba sacar la información del disco duro y todavía no diagnosticábamos el problema.
Realizamos la habitual exportación a través de mysqldump, la cual no habíamos notado del error porque usábamos un script bash que no lo mostraba al momento, nos dimos cuenta fue porque el archivo SQL generado no tenía el tamaño adecuado, de una base de datos unos 600mb solo se logró exportar 80mb. Entonces al correr directamente el código para el dump fue que aparecía el mensaje de error:
«mysqldump: Error 2013: Lost connection to MySQL server during query»
Este error es poco común y puede ocurrir cuando se satura la memoria, a veces cuando no tiene espacio en disco pero para ello envía otro mensaje por falta de espacio. Sabíamos que no podía ser por memoria, ya que el servidor manejaba 16gb de RAM, suficiente para cualquier aplicación, el disco estaba prácticamente vacío y como solo teníamos una aplicación, no había ningún proceso que saturara la memoria. Era por el fallo eléctrico porque recibíamos muchos errores tanto de memoria procesador y se reiniciaba el servidor automáticamente cada 5 minutos.
Luego de un arduo trabajo pudimos exportar correctamente luego de realizar los siguientes intentos:
Primero probamos con el habitual comando:
|
1 |
mysqldump --user=TU_USUARIO --password=TU_PASSWORD --opt --skip-add-drop-table --databases TU_BD > /TU_BD.sql |
El cual nos arrojaba el error anterior, siempre se detenia alrededor de los 80mb.
Para agilizar el exportado, es recomendable agregar la opción spkip-extended-insert, la cual se utiliza para volcar la información en varios INSERT por línea y así evitar un solo insert gigantesco por tabla que es lo común, en este caso no nos funcionó, no era ese el problema.
|
1 |
mysqldump --user=TU_USUARIO --password=TU_PASSWORD --spkip-extended-insert --opt --skip-add-drop-table --databases TU_BD > /TU_BD.sql |
Otra cuestión es que el –opt habilita las opciones para mayor velocidad, –quick y el extended-insert y también están activas por defecto, se cambió en el script y se agregó otras dos opciones –lock-tables=false para evitar más consumo de recursos (no es recomendable si está en uso la bd), aparte se agregó –max_allowed_packet=128M para incrementar la memoria permitida por paquete:
|
1 |
mysqldump --user=TU_USUARIO --password=TU_PASSWORD --opt --skip-add-drop-table --max_allowed_packet=128M --skip-quick --lock-tables=false --databases TU_BD > /TU_BD.sql |
Ese sería el definitivo y como teníamos problemas generales por lo inestable del sistema tuvimos que agregarlo en la configuración de mysql /etc/mysql/my.cnf y aunque con reiniciar el servicio, ya toma la configuración, tuvimos que reiniciar el servidor para evitar inconvenientes con la memoria.
Agregamos la opción bajo [mysqld], puede ser en megas 128M, o gigas 1G, tomando en cuenta que el minimo y máximo varía por versión de mysql https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_max_allowed_packet y lo máximo es 1GB, el cual no necesitamos pero si es una emergencia de una sola ocasión puedes intentarlo.
[mysqld]
max_allowed_packet = 128M
Si existe la opción [mysqldump], también debe agregarse allí:
[mysqldump]
max_allowed_packet = 128M
Para ser más precisos puedes usar el monto del enlace que está en bytes (1GB) en caso de emergencia:
max_allowed_packet = 1073741824
Luego de esto pudimos exportar con cualquiera de los script mencionados arriba. Esto también sirve para los errores de «Packet Too Large» y el otro «MySQL server has gone away».
