Cuando realizamos una restauración de un archivo sql muy grande es muy común que nos de un error:
ERROR 2006 (HY000): MySQL server has gone away
Este error se soluciona realmente fácil simplemente hay que configurar el valor max_allowed_packet en el archivo de configuracion my.cf de MySQL/MariaDB
En mi caso se ubica en /etc/my.cf aunque en su caso puede llamarse diferente y estar ubicado en otra carpeta, depende de la distribución. Editamos el archivo y agregamos max_allowed_packet:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
max_allowed_packet=128M
Guardamos los cambios, reiniciamos el servicio MySQL o MariaDB, ahora también es posible que no tengamos un archivo de configuración como este y las variables se tengan que configurar desde la propia consola de mysql:
[root@server] mysql -u root -p
MariaDB [(none)]> SET GLOBAL max_allowed_packet=134217728;
Ahora ya podemos importar sin problemas, en caso necesario se puede subir más los valores, en el caso de hacerlo por consola el valor se coloca en bytes, por ejemplo se coloca 134217728 para 128MB o 1073741824 si queremos configurar 1GB.
Administrador de Sistemas, Programador, Docente y ahora resulta que también Blogger (peor es ser tictoker). Más de 20 años de experiencia en computación atendiendo nabos y resolviendo problemas que sino fuera por estos nabos no habrían ocurrido en primer lugar. Escribo más que nada sobre tecnología y herramientas en general además de algunos artículos con opiniones tan subjetivas como irrelevantes, así que si no te gustan mejor madura.
Muchas gracias por la explicación, me aclaró cuál era el problema, ya que tenía este error al hacer un import de un mysqldump era incapaz de adivinarlo con el texto del error… Agregado el parámetro al my.cnf con el valor del tamaño del dump que quería importar (15G en mi caso) y resuelto!
Hola
Muchas gracias por tu comentario, me alegro mucho que te haya servido, en realidad el valor no necesita ser superior al tamaño del archivo porque no se procesa todo el archivo al mismo tiempo, esta mas vinculado al tamaño de las consultas, es decir el error lo da cuando la consulta, o las consultas, porque en realidad no se sino las toma en bloque, son mayores a ese buffer y ahi da el error, recuerda que por ejemplo se puede insertar cientos y cientos de registros en una sola consulta insert lo cual insume mucha memoria, capas que en algun caso puedes necesitar un valor mayor aunque con un valor de 256MB o 512MB debería funcionar perfecto sin importar que sea un dumps 100 veces mas grande.
Hola Alvaro:
Yo he subido el valor hasta 1GB. EL problema se me presenta en un backup (DUMP) que va a un STORAGE. He pensado que el problema va en el timeout del storage, pero si fuera así, el error 2006 no aparecería en el log de errores.
El último respaldo aparentemente completo fue el 31/12/2019 y era de 16GB, ahora sólo llegan an 11GB por el error me imagino, ya que no sigue generando el backup. Deberé subir el parámetro a 16GB como dice el amigo del comentario anterior?.
Ojalá me puedas ayudar. Suerte y a cuidarse del coronavirus. Saludos.
Ramón Aravena
Hola Ramon
No es necesario subirlo hasta 16 porque no es un tema del tamaño del dump, el valor es solo un buffer interno, ademas nunca he visto este error para exportar la base de datos, al menos a mi no me ha tocado, calculo que tu problema viene por otro lado.
Yo probaría hacer el dump locamente en lugar de storage para verificar que se haga completo, hay muchas razones para que un dump se corte como por ejemplo una tabla con registros corruptos
Luego sabiendo que esta completo probaría transferirlo manualmente, ahí verificas que si problema esta en el storage y no en el dump, así mismo verificaría que en el storage tengas suficiente espacio y los permisos adecuados.
Saludos
Alvaro:
Muchísimas gracias por tu respuesta.
Me queda probar lo que dices y esperar que el servidor tenga los recursos para un respaldo de 16GB locales, ya que el uso del STORAGE montado en el servidor es por eso, falta de disco. Pero debo verlo con el área adecuada.
Lo otro, si puedes por favor: Cómo hago una visualización rápida de qué tablas son las corruptas.
EL escenario es que el DUMP alcanza a respaldar unos 11GB, poco más de las mitad de las tablas y el LOG DE ERROR capturado me indica muchas tablas que NO alcanzaron a respaldarse.
Gracias de antemano.
Saludos cordiales y a cuidarse del Covid-19
Ramón
Hola Ramon
Asumiendo que es un servidor Linux tienes mysqlcheck, no se si en Windows venga, funciona asi:
mysqlcheck -c nombre_base_de_datos
Te dice si las tablas estan OK o no, luego para reparar:
mysqlcheck –repair nombre_base_de_datos
Para ver si un dump esta completo haces:
tail ejemplo.sql
En la ultima linea te debe decir si el dump se completo
Saludos
Alvaro:
Muchísimas gracias. Ejecutaré los comandos para revisar la BD, pues pienso que algo ha pasado con algunas tablas, puesto que hasta el 31/12/2019 el respaldo terminaba bien y nada ha cambiado, excepto que alguna tabla está corrupta, o varias.
Suerte con todo, gracias de nuevo.
Hola:
Para completar el tema y por si le pasa a alguien más este problema. El DUMP con el error 2006 se completó SIN ERRORES modificando el parámetro “max_allowed_packet” directamente en el comando, de esta manera:
mysqldump -u root -p –create-options –max_allowed_packet=128M –routines –force — BD > Archivo_de_respaldo.sql
Espero que a alguien se sirva.
Saludos,
Ramón
Grande!!!!!!
buenisimo muchas gracias