sqlstate mysqli_real_connect hy000 has gone general error code away mysql

mysqli_real_connect - sqlstate hy000]: general error 2006 mysql server has gone away



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

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

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

Recibo este error cuando intento obtener un archivo SQL grande (una gran consulta INSERT ).

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. He intentado eliminar y recuperar la tabla / base de datos, así como reiniciar MySQL. Ninguna de estas cosas resuelve el problema.

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

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

Aquí está el tamaño del archivo:

$ ls -s file.sql 79512 file.sql

Cuando intento 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

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 import

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

Así que tienes las siguientes posibilidades:

  • Agregue la opción de fuerza ( -f ) para que mysql proceda y ejecute el resto de las consultas.

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

  • Aumente max_allowed_packet y wait_timeout en la configuración de su servidor (por ejemplo, ~/.my.cnf ).

  • Vuelque la base de datos con la opción --skip-extended-insert para desglosar las consultas grandes. Luego importarlo de nuevo.

  • Intente aplicar la --max-allowed-packet para mysql .

Razones comunes

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

  • una consulta al servidor es incorrecta o demasiado grande,

    Solución: Aumente la variable max_allowed_packet .

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

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

    • No te olvides de reiniciar el servidor MySQL / MariaDB.

    • Verifique nuevamente que el valor se haya establecido correctamente por:

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

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

    Solución: Aumente la variable wait_timeout .

  • Intentó ejecutar una consulta después de cerrar la conexión con el servidor.

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

  • Las búsquedas de nombres de host han fallado (por ejemplo, un problema con el servidor DNS), o el servidor se ha iniciado con la opción --skip-networking .

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

  • El hilo en ejecución ha sido eliminado, así que vuelve a intentarlo.

  • Ha encontrado un error en el que el servidor murió al ejecutar 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 ha desaparecido .

Depuración

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

  • Compruebe los registros, por ejemplo

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

  • Pruebe su conexión a través de mysql , telnet o funciones de ping (por ejemplo, mysql_ping en PHP).

  • Use tcpdump para detectar la comunicación de 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 , por ejemplo

    sudo dtruss -a -fn mysqld 2>&1

    Ver: Comenzando con DTracing MySQL

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

Para referencia, verifique el código fuente en el archivo sql-common/client.c responsable de lanzar el error CR_SERVER_GONE_ERROR 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; }

Encontré este error cuando uso Mysql Cluster, no sé si esta pregunta proviene de un uso de cluster o no. Como el error es exactamente el mismo, dale mi solución aquí. Obteniendo este error porque los nodos de datos de repente se estrellan. Pero cuando los nodos se bloquean, aún puede obtener el resultado correcto utilizando 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 más tarde, el resultado de ndb_mgm no muestra ningún nodo de datos funcionando. 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 para algunas consultas, cuando uso cmd como show tables , todavía puedo obtener la información de retorno como 33 rows in set (5.57 sec) , pero no se muestra información de la tabla.

Este es un problema poco frecuente, pero he visto esto si alguien ha copiado el directorio / var / lib / mysql completo 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. No funciona a veces si hay registros en / var / log / mysql. La solución es copiar los archivos / var / log / mysql también.

La actualización global y la configuración de my.cnf no funcionaron para mí por alguna razón. Pasando el valor max_allowed_packet directamente al cliente trabajado aquí:

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

La solución es aumentar los valores dados los wait_timeout y connect_timeout en su archivo de opciones, bajo la etiqueta [mysqld] .

Tuve que recuperar una copia de seguridad de MySQL de 400MB y esto me funcionó (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

Para Amazon RDS (es mi caso), puede cambiar el valor del parámetro max_allowed_packet 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_packet a 64M = 67108864), en un parameter-group nuevo o existente. Luego aplique ese grupo de parámetros a su instancia de MySQL (puede que sea necesario reiniciar la instancia).

Por si acaso, para comprobar las variables se pueden utilizar.

$> 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 away y migró con éxito un archivo sql> 5GB al realizar estos dos pasos en orden:

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

    max_allowed_packet=500M

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

Nota importante: fue necesario realizar ambos pasos, ya que si no me molestaba en hacer los cambios en el archivo /etc/my.cnf, así como en añadir esos indicadores, 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)

Si ninguna de estas respuestas le resuelve el problema, lo resolví eliminando las tablas y volviéndo a crearlas 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 simplemente 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á.

Si se está reconectando y obteniendo la ID de conexión 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 algún error operacional importante, 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 la memoria virtual. El registro de errores de MySQL probablemente tendrá alguna información relevante; Ellos estarán monitoreando esto si son competentes de todos modos.

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

[mysqld] max_allowed_packet=64M

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

show variables like ''max_allowed_packet'';

Y confirme el cambio después de haber reiniciado MySQL:

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

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

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

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

añadir una línea

set global max_allowed_packet=64*1024*1024;

ahora reinicia el servicio MySQL una vez que hayas terminado.

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

  • Su INSERT está ejecutando durante 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 de proceso por lotes desde la línea de comando y seleccionar la base de datos en los argumentos, por lo tanto;

$ mysql db_name <source.sql

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

max_allowed_packet=64M

Agregar esta línea en el archivo my.cnf resuelve mi problema.

Esto es útil cuando las columnas tienen valores grandes, lo que causa los problemas, puede encontrar la explicación here .

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

En Linux (Ubuntu): / etc / mysql