Error de MySQL 2006: el servidor mysql ha desaparecido

He encontrado esto varias veces y normalmente he encontrado que la respuesta es una configuración predeterminada muy baja de max_allowed_packet. Elevarlo en /etc/my.cnf (bajo [mysqld]) a 8 o 16M generalmente lo arregla.

[mysqld]
max_allowed_packet=16M

Nota: Esto se puede configurar en su servidor mientras se está ejecutando.

Use set global max_allowed_packet=104857600. Esto lo establece en 100MB.

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

Añadir una línea

Max_allowed_packet = 500M

Ahora restart the MySQL service una vez que haya terminado.

Usé el siguiente comando en la línea de comandos de MySQL para restaurar una base de datos MySQL que tenga un tamaño superior a 7 GB, y funciona.

set global max_allowed_packet=268435456;

En MAMP (versión no pro) agregué

--max_allowed_packet=268435456

A ...\MAMP\bin\startMysql.sh

Créditos y más detalles aquí

Error: 2006 (CR_SERVER_GONE_ERROR )

Mensaje: El servidor MySQL se ha ido

Generalmente puede volver a intentar conectarse y luego hacer la consulta de nuevo para resolver este problema, intente como 3-4 veces antes de rendirse por completo.

Asumiré que estás usando PDO. Si es así, entonces cogería la excepción PDO, incrementaría un contador y luego intentaría de nuevo si el contador está por debajo de un umbral.

Si tiene una consulta que está causando un tiempo de espera, puede establecer esta variable ejecutando:

SET @@GLOBAL.wait_timeout=300;
SET @@LOCAL.wait_timeout=300;  -- OR current session only

Donde 300 es el número de segundos que cree que el tiempo máximo que la consulta podría tomar.

Más información sobre cómo tratar los problemas de conexión de Mysql.

EDITAR: Otras dos configuraciones que puede usar también son net_write_timeout y net_read_timeout.

Este error se produce debido a la expiración de wait_timeout .

Simplemente vaya al servidor mysql compruebe su wait_timeout:

Mysql > MOSTRAR VARIABLES COMO'wait_timeout'

Mysql > establecer wait_timeout global = 600 # 10 minutos o tiempo de espera máximo hacia fuera usted necesita

Http://sggoyal.blogspot.in/2015/01/2006-mysql-server-has-gone-away.html

Estaba recibiendo este mismo error en mi servidor Ubuntu DigitalOcean.

Intenté cambiar la configuración max_allowed_packet y wait_timeout, pero ninguno de ellos lo arregló.

Resulta que mi servidor estaba sin RAM. Agregué un archivo de intercambio de 1 GB y eso solucionó mi problema.

Revisa tu memoria con free -h para ver si eso es lo que la está causando.

En Windows los chicos que usan xampp deben usar esta ruta xampp/mysql/bin/my.ini y cambie max_allowed_packet (en la sección[mysqld])al tamaño de su elección. por ejemplo,

max_allowed_packet=8M

De nuevo en php.ini (xampp / php / php.ini) cambiar upload_max_filesize el tamaño de elección. por ejemplo,

upload_max_filesize=8M

Me dio dolor de cabeza por algún tiempo hasta que descubrí esto. Espero que ayude.

Para Vagrant Box, asegúrese de asignar suficiente memoria a la caja

config.vm.provider "virtualbox" do |vb|
  vb.memory = "4096"
end

En mi caso fue un valor bajo de la variable open_files_limit, lo que bloqueó el acceso de mysqld a los archivos de datos.

Lo comprobé con:

mysql> SHOW VARIABLES LIKE 'open%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 1185  |
+------------------+-------+
1 row in set (0.00 sec)

Después de cambiar la variable a big value, nuestro servidor estaba vivo de nuevo :

[mysqld]
open_files_limit = 100000

Fue un problema de RAM para mí.

Estaba teniendo el mismo problema incluso en un servidor con 12 núcleos de CPU y 32 GB de RAM. Investigué más y traté de liberar RAM. Aquí está el comando que usé en Ubuntu 14.04 para liberar RAM:

sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

Y, lo arregló todo. Lo he puesto bajo cron para que funcione cada hora.

crontab -e

0 * * * * bash /root/ram.sh;

Y, puede usar este comando para verificar cuánta RAM libre está disponible:

free -h

Y obtendrás algo como esto:

             total       used       free     shared    buffers     cached
Mem:           31G        12G        18G        59M       1.9G       973M
-/+ buffers/cache:       9.9G        21G
Swap:         8.0G       368M       7.6G

El escenario poco probable es que tenga un firewall entre el cliente y el servidor que fuerza el restablecimiento TCP en la conexión.

Tuve ese problema, y encontré que nuestro firewall corporativo F5 estaba configurado para terminar las sesiones inactivas que están inactivas durante más de 5 minutos.

Una vez más, este es el escenario improbable.

Si está utilizando el SERVIDOR WAMP de 64 bits, busque múltiples ocurrencias de max_allowed_packet porque WAMP usa el valor establecido en [wampmysqld64] y no el valor establecido en [mysqldump], que para mí fue el problema, estaba actualizando el incorrecto. Establezca esto en algo como max_allowed_packet = 64M.

Esperemos que esto ayude a otros usuarios de Wampserver.

Descomente la línea de abajo en su my.ini/my.cnf, esto dividirá su archivo grande en una porción más pequeña

# binary logging format - mixed recommended
# binlog_format=mixed

A

# binary logging format - mixed recommended
binlog_format=mixed

He encontrado la solución a "#2006 - MySQL server has gone away" este error. La solución es solo que usted tiene que comprobar dos archivos

1. config.inc.php
2. config.muestra.inc.php

La ruta de estos archivos en Windows es

C:\wamp64\apps\phpmyadmin4.6.4

En estos dos archivos el valor de esto:

$cfg['Servers'][$i]['host']must be 'localhost' .

En mi caso fue:

$cfg['Servers'][$i]['host'] = '127.0.0.1';

Cámbialo a:

"$cfg['Servers'][$i]['host']" = 'localhost';

Asegúrese en ambos:

1. config.inc.php
2. config.muestra.inc.archivos php debe ser 'localhost'.

Y último conjunto:

$cfg['Servers'][$i]['AllowNoPassword'] = true;

Luego reinicie Wampserver.

Para cambiar el nombre de usuario y la contraseña de phpmyadmin

Puede cambiar directamente el nombre de usuario y la contraseña de phpmyadmin a través de config.inc.archivo php

Estas dos líneas

$cfg['Servers'][$i]['user'] = 'root';
$cfg['Servers'][$i]['password'] = '';

Aquí puede dar un nuevo nombre de usuario y contraseña. Después de los cambios guarde el archivo y reinicie el servidor WAMP.

Esto generalmente indica problemas de conectividad del servidor MySQL o tiempos de espera. Generalmente se puede resolver cambiando wait_timeouty max_allowed_packeten mi.cnf o similar.

Yo sugeriría estos valores:

Wait_timeout = 28800

Max_allowed_packet = 8M

Recibí el mensaje de error 2006 en diferentes software de clientes MySQL en mi escritorio Ubuntu. Resultó que mi versión del controlador JDBC era demasiado vieja.

Esto podría ser un problema suyo .tamaño de archivo sql.

Si está utilizando xampp. Vaya al panel de control de xampp -> Haga clic en MySQL config -> Abrir mi.ini.

Aumentar el tamaño del paquete.

max_allowed_packet = 2M -> 10M

Para los usuarios que usan XAMPP, hay 2 max_allowed_packet parámetros en C:\xampp\mysql\bin\my.ini.

Siempre es una buena idea revisar los registros del servidor Mysql, por la razón por la que desapareció.

Se lo dirá.

Este error ocurre básicamente por dos razones.

1. Tienes un carnero demasiado bajo.
2. La conexión a la base de datos se cierra cuando intenta conectarse.

Puede probar este código a continuación.

# Simplification to execute an SQL string of getting a data from the database
def get(self, sql_string, sql_vars=(), debug_sql=0):
    try:            
        self.cursor.execute(sql_string, sql_vars)
        return self.cursor.fetchall()
    except (AttributeError, MySQLdb.OperationalError):
        self.__init__()
        self.cursor.execute(sql_string, sql_vars)
        return self.cursor.fetchall()

Mitiga el error cualquiera que sea la razón detrás de él, especialmente por la segunda razón.

Si se debe a una RAM baja, debe aumentar la eficiencia de conexión de la base de datos desde el código, desde la configuración de la base de datos, o simplemente aumentar la RAM.

Si sabe que va a desconectarse por un tiempo, puede cerrar su conexión, hacer su procesamiento, volver a conectarse y escribir sus informes.