ERROR 2006 (HY000): el servidor MySQL se ha ido

Recibo este error cuando intento obtener un archivo SQL grande (una INSERTconsulta grande ).

mysql>  source file.sql
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    2
Current database: *** NONE ***

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    3
Current database: *** NONE ***

Nada en la tabla se actualiza. Intenté eliminar y recuperar la tabla / base de datos, así como reiniciar MySQL. Ninguna de estas cosas resuelve el problema.

Aquí está el tamaño máximo de mi paquete:

+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+

Aquí está el tamaño del archivo:

$ ls -s file.sql 
79512 file.sql

Cuando pruebo el otro método ...

$ ./mysql -u root -p my_db < file.sql
Enter password: 
ERROR 2006 (HY000) at line 1: MySQL server has gone away

max_allowed_packet=64M

Agregar esta línea al my.cnfarchivo resuelve mi problema.

Esto es útil cuando las columnas tienen valores grandes, que causan los problemas, puede encontrar la explicación aquí .

En Windows, este archivo se encuentra en: "C: \ ProgramData \ MySQL \ MySQL Server 5.6"

En Linux (Ubuntu): / etc / mysql

Puede aumentar el paquete máximo permitido

SET GLOBAL max_allowed_packet=1073741824;

http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet

La actualización global y la configuración de my.cnf no me funcionaron por alguna razón. Pasar el max_allowed_packetvalor directamente al cliente trabajó aquí:

mysql -h <hostname> -u username -p --max_allowed_packet=1073741824 <databasename> < db.sql

En general el error:

Error: 2006 ( CR_SERVER_GONE_ERROR) - El servidor MySQL se ha ido

significa que el cliente no pudo enviar una pregunta al servidor .

mysql importar

En su caso específico al importar el archivo de la base de datos a través de mysql, esto probablemente significa que algunas de las consultas en el archivo SQL son demasiado grandes para importar y no se pudieron ejecutar en el servidor, por lo tanto, el cliente falla en el primer error ocurrido.

Entonces tienes las siguientes posibilidades:

• Agregue la opción force ( -f) para mysqlcontinuar y ejecutar el resto de las consultas.

  Esto es útil si la base de datos tiene algunas consultas grandes relacionadas con la memoria caché que de todos modos no son relevantes.

• Aumente max_allowed_packetywait_timeout en la configuración de su servidor (por ejemplo ~/.my.cnf).

• Volcar la base de datos usando la --skip-extended-insertopción para desglosar las consultas grandes. Luego impórtalo de nuevo.

• Intenta aplicar la --max-allowed-packetopción para mysql.

Razones comunes

En general, este error podría significar varias cosas, como:

• una consulta al servidor es incorrecta o demasiado grande,

  Solución: aumentar la max_allowed_packetvariable .

  • Asegúrese de que la variable esté debajo de la [mysqld]sección, no [mysql].

  • No tenga miedo de usar números grandes para las pruebas (como 1G).

  • No olvide reiniciar el servidor MySQL / MariaDB.

  • Verifique dos veces que el valor se haya establecido correctamente:

    mysql -sve "SELECT @@max_allowed_packet" # or:
    mysql -sve "SHOW VARIABLES LIKE 'max_allowed_packet'"

• Se agotó el tiempo de espera de la conexión TCP / IP en el lado del cliente.

  Solución: aumentar la wait_timeoutvariable .

• Intentó ejecutar una consulta después de que se cerró la conexión al servidor.

  Solución: Se debe corregir un error lógico en la aplicación.

• Las búsquedas de nombres de host fallaron (p. Ej., Problema del servidor DNS) o el servidor se inició con la --skip-networkingopción.

  Otra posibilidad es que su firewall bloquee el puerto MySQL (por ejemplo, 3306 por defecto).

• El subproceso en ejecución se ha eliminado, así que vuelva a intentarlo

• Ha encontrado un error en el que el servidor murió mientras ejecutaba la consulta.

• Un cliente que se ejecuta en un host diferente no tiene los privilegios necesarios para conectarse.

• Y muchos más, así que aprenda más en: B.5.2.9 El servidor MySQL se ha ido .

Depuración

Aquí hay algunas ideas de depuración de nivel experto:

• Verifique los registros, p. Ej.

  sudo tail -f $(mysql -Nse "SELECT @@GLOBAL.log_error")

• Pruebe su conexión a través de mysql, telneto funciones de ping (por ejemplo, mysql_pingen PHP).

• Úselo tcpdumppara detectar la comunicación MySQL (no funcionará para la conexión de socket), por ejemplo:

  sudo tcpdump -i lo0 -s 1500 -nl -w- port mysql | strings

• En Linux, use strace. En BSD / Mac use dtrace/ dtruss, p. Ej.

  sudo dtruss -a -fn mysqld 2>&1

  Ver: Primeros pasos con DTracing MySQL

Obtenga más información sobre cómo depurar el servidor o cliente MySQL en: 26.5 Depuración y portabilidad de MySQL .

Como referencia, verifique el código fuente en el sql-common/client.carchivo responsable de arrojar el CR_SERVER_GONE_ERRORerror para el comando del cliente.

MYSQL_TRACE(SEND_COMMAND, mysql, (command, header_length, arg_length, header, arg));
if (net_write_command(net,(uchar) command, header, header_length,
          arg, arg_length))
{
  set_mysql_error(mysql, CR_SERVER_GONE_ERROR, unknown_sqlstate);
  goto end;
}

Por si acaso, para verificar las variables puede usar

$> mysqladmin variables -u user -p 

Esto mostrará las variables actuales, en este caso max_allowed_packet, y como alguien dijo en otra respuesta, puede configurarlo temporalmente con

mysql> SET GLOBAL max_allowed_packet=1072731894

En mi caso, el archivo cnf no se tuvo en cuenta y no sé por qué, por lo que el código SET GLOBAL realmente ayudó.

Resolví el error ERROR 2006 (HY000) at line 97: MySQL server has gone awayy migré con éxito un archivo sql> 5GB realizando estos dos pasos en orden:

1. Creó /etc/my.cnf como otros lo han recomendado, con los siguientes contenidos:

   [mysql]
   connect_timeout = 43200
   max_allowed_packet = 2048M
   net_buffer_length = 512M
   debug-info = TRUE

2. Agregar las banderas --force --wait --reconnectal comando (es decir mysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect).

Nota importante: Era necesario realizar ambos pasos, porque si no me molestaba en hacer los cambios en el archivo /etc/my.cnf y en agregar esas marcas, faltaban algunas de las tablas después de la importación.

Sistema utilizado: OSX El Capitan 10.11.5; mysql Ver 14.14 Distrib 5.5.51 para osx10.8 (i386)

Tuve el mismo problema, pero cambiar max_allowed_packet en el archivo my.ini / my.cnf en [mysqld] hizo el truco.

agregar una línea

max_allowed_packet=500M

ahora reinicie el servicio MySQL una vez que haya terminado.

También puede iniciar sesión en la base de datos como root (o privilegio SUPER) y hacer

set global max_allowed_packet=64*1024*1024;

no requiere un reinicio de MySQL también. Tenga en cuenta que debe corregir su my.cnfarchivo como se describe en otras soluciones:

[mysqld]
max_allowed_packet=64M

Y confirme el cambio después de reiniciar MySQL:

show variables like 'max_allowed_packet';

También puede usar la línea de comandos, pero eso puede requerir la actualización de los scripts de inicio / detención que pueden no sobrevivir a las actualizaciones y parches del sistema.

Según lo solicitado, agrego mi propia respuesta aquí. Me alegra ver que funciona!

La solución es aumentar los valores dados wait_timeouty los connect_timeoutparámetros en su archivo de opciones, debajo de la [mysqld]etiqueta.

Tuve que recuperar una copia de seguridad de MySQL de 400 MB y esto funcionó para mí (los valores que he usado a continuación son un poco exagerados, pero entiendes el punto):

[mysqld]
port=3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_write_timeout = 1000000
wait_timeout = 1000000
max_allowed_packet = 1024M
interactive_timeout = 1000000
net_buffer_length = 200M
net_read_timeout = 1000000
set GLOBAL delayed_insert_timeout=100000

Blockquote

Un par de cosas podrían estar sucediendo aquí;

• Se INSERTestá ejecutando mucho tiempo y el cliente se está desconectando Cuando se vuelve a conectar, no está seleccionando una base de datos, de ahí el error. Una opción aquí es ejecutar su archivo por lotes desde la línea de comandos y seleccionar la base de datos en los argumentos, así;

$ mysql db_name <source.sql

• Otro es ejecutar su comando a través de phpo algún otro idioma. Después de cada declaración de larga duración, puede cerrar y volver a abrir la conexión, asegurándose de estar conectado al comienzo de cada consulta.

Si está en Mac e instaló mysql a través de brew como yo, lo siguiente funcionó.

1. cp $(brew --prefix mysql)/support-files/my-default.cnf /usr/local/etc/my.cnf

Fuente: para las instalaciones de mysql de homebrew, ¿dónde está my.cnf?

2. agregar max_allowed_packet=1073741824a/usr/local/etc/my.cnf

3. mysql.server restart

Encontré este error cuando uso Mysql Cluster, no sé si esta pregunta es de un uso de clúster o no. Como el error es exactamente el mismo, da mi solución aquí. Obteniendo este error porque los nodos de datos se bloquean de repente. Pero cuando los nodos se bloquean, aún puede obtener el resultado correcto usando cmd:

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

Y el mysqld también funciona correctamente. Entonces, al principio, no puedo entender lo que está mal. Y unos 5 minutos después, el resultado ndb_mgm muestra que no funciona ningún nodo de datos. Entonces me doy cuenta del problema. Entonces, intente reiniciar todos los nodos de datos, luego el servidor mysql está de vuelta y todo está bien.

Pero una cosa es extraña para mí, después de que perdí el servidor mysql por algunas consultas, cuando uso cmd like show tables, todavía puedo obtener la información de retorno 33 rows in set (5.57 sec), pero no se muestra la información de la tabla.

Para Amazon RDS (es mi caso), puede cambiar el max_allowed_packetvalor del parámetro a cualquier valor numérico en bytes que tenga sentido para los datos más grandes en cualquier inserción que pueda tener (por ejemplo: si tiene algunos valores de blob de 50mb en su inserción, establezca max_allowed_packeta 64M = 67108864), en una nueva o existente parameter-group. Luego aplique ese grupo de parámetros a su instancia de MySQL (puede requerir reiniciar la instancia).

Si se está reconectando y obteniendo la conexión ID 2, el servidor casi definitivamente se ha bloqueado.

Póngase en contacto con el administrador del servidor y pídales que diagnostiquen el problema. Ningún SQL no malicioso debería bloquear el servidor, y la salida de mysqldump ciertamente no debería.

Es probable que el administrador del servidor haya cometido un gran error operativo, como asignar tamaños de búfer mayores que los límites de espacio de direcciones de la arquitectura, o más que la capacidad de memoria virtual. El registro de errores de MySQL probablemente tendrá información relevante; supervisarán esto si son competentes de todos modos.

Este es un problema más raro, pero lo he visto si alguien ha copiado todo el directorio / var / lib / mysql como una forma de migrar su base de datos a otro servidor. La razón por la que no funciona es porque la base de datos se estaba ejecutando y usando archivos de registro. A veces no funciona si hay registros en / var / log / mysql. La solución es copiar también los archivos / var / log / mysql.

Para usuarios de Drupal 8 que buscan una solución para la falla de importación de DB:

Al final del archivo de volcado sql puede haber comandos que insertan datos en la tabla "webprofiler". Supongo que es un archivo de registro de depuración y no es realmente importante para que el sitio funcione, por lo que todo esto se puede eliminar. Eliminé todas esas inserciones, incluidas LOCK TABLES y UNLOCK TABLES (y todo lo demás). Está en la parte inferior del archivo sql. El problema se describe aquí:

https://www.drupal.org/project/devel/issues/2723437

Pero no hay solución para esto además de truncar esa tabla.

Por cierto, probé todas las soluciones de las respuestas anteriores y nada más me ayudó.

He intentado todas las soluciones anteriores, todas fallaron.

Terminé usando en -h 127.0.0.1lugar de usar el predeterminado var/run/mysqld/mysqld.sock.

Este mensaje de error también aparece cuando creó el SCHEMA con una COLLATION diferente a la que se utiliza en el volcado. Entonces, si el volcado contiene

CREATE TABLE `mytab` (
..
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

también debe reflejar esto en la recopilación de SCHEMA:

CREATE SCHEMA myschema COLLATE utf8_unicode_ci;

Había estado usando utf8mb4_general_ci en el esquema, porque mi script provenía de una nueva instalación de V8, ahora cargaba un DB en el viejo 5.7 y se volvía loco.

Entonces, tal vez esto te ayude a ahorrar algunas horas frustrantes ... :-)

(MacOS 10.3, mysql 5.7)

Si ninguna de estas respuestas resuelve el problema, lo resolví eliminando las tablas y volviéndolas a crear automáticamente de esta manera:

when creating the backup, first backup structure and be sure of add:
DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT
CREATE PROCEDURE / FUNCTION / EVENT
IF NOT EXISTS
AUTO_INCREMENT

luego use esta copia de seguridad con su base de datos y eliminará y volverá a crear las tablas que necesita.

Luego hace una copia de seguridad de los datos y hace lo mismo, y funcionará.

¿Qué tal usar el cliente mysql de esta manera?

mysql -h <hostname> -u username -p <databasename> < file.sql