password - Código de error: 2013. Conexión perdida al servidor MySQL durante la consulta
authentication to host localhost for user root using method mysql_native_password (24)
Agregue lo siguiente en el archivo / etc / mysql / cnf:
innodb_buffer_pool_size = 64M
ejemplo:
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
innodb_buffer_pool_size = 64M
Obtuve el Código de error: 2013. Perdí la conexión con el servidor MySQL durante el error de consulta cuando intenté agregar un índice a una tabla utilizando MySQL Workbench. También noté que aparece cada vez que ejecuto una consulta larga.
¿Hay alguna posibilidad de aumentar el valor de tiempo de espera?
Cambie el tiempo de "tiempo de espera de lectura" en Editar-> Preferencias-> Editor de SQL-> sesión de MySQL
Debe establecer las propiedades ''interactive_timeout'' y ''wait_timeout'' en el archivo de configuración de mysql en los valores que necesita.
Esto generalmente significa que tiene "incompatibilidades con la versión actual del servidor MySQL", vea mysql_upgrade. Me encontré con este mismo problema y simplemente tuve que ejecutar:
mysql_upgrade --password La documentación indica que, "mysql_upgrade debe ejecutarse cada vez que actualice MySQL".
Esto me sucedió porque mi innodb_buffer_pool_size se configuró para ser más grande que el tamaño de RAM disponible en el servidor. Las cosas fueron interrumpidas por esto y se emite este error. La solución es actualizar my.cnf con la configuración correcta para innodb_buffer_pool_size.
Gracias! Ha funcionado. Pero con las actualizaciones mysqldb, la configuración se convirtió en:
max_allowed_packet
net_write_timeout
net_read_timeout
Hay tres causas probables para este mensaje de error
- Por lo general, indica problemas de conectividad de red y debe verificar el estado de su red si este error ocurre con frecuencia.
- A veces, el formulario "durante la consulta" se produce cuando se envían millones de filas como parte de una o más consultas.
- Más raramente, puede suceder cuando el cliente está intentando la conexión inicial con el servidor
Para más detalles leer >>
Causa 2:
SET GLOBAL interactive_timeout=60;
de su valor predeterminado de 30 segundos a 60 segundos o más
Causa 3:
SET GLOBAL connect_timeout=60;
Intente desmarcar las filas de límite en Editar → Preferencias → Consultas SQL
porque debe establecer las propiedades ''interactive_timeout'' y ''wait_timeout'' en el archivo de configuración de mysql en los valores que necesita.
Ir:
Editar -> Preferencias -> Editor de SQL
Allí puede ver tres campos en el grupo "Sesión MySQL", donde ahora puede establecer los nuevos intervalos de conexión (en segundos).
Las nuevas versiones de MySQL WorkBench tienen una opción para cambiar los tiempos de espera específicos.
Para mí fue en Editar → Preferencias → Editor de SQL → Tiempo de espera de lectura de conexión DBMS (en segundos): 600
Cambió el valor a 6000.
También se limitan las filas de límite, ya que poner límite en cada vez que quiero buscar en todo el conjunto de datos es tedioso.
Me encontré con esto mientras ejecutaba un proceso almacenado que creaba muchas filas en una tabla en la base de datos. Pude ver el error venir justo después de que el tiempo cruzó el límite de 30 segundos.
Intenté todas las sugerencias en las otras respuestas. Estoy seguro de que algo ayudó, sin embargo, lo que realmente hizo que funcionara para mí fue cambiar a SequelPro desde Workbench.
Supongo que fue una conexión del lado del cliente que no pude detectar en Workbench. Tal vez esto ayudará a alguien más también?
Me enfrenté a este mismo problema. Creo que sucede cuando tienes claves externas para tablas más grandes (lo que lleva tiempo).
Traté de ejecutar la declaración create table nuevamente sin las declaraciones de clave externa y encontré que funcionó.
Luego, después de crear la tabla, agregué las restricciones de la clave externa usando la consulta ALTER TABLE.
Espero que esto ayude a alguien.
Resulta que nuestra regla de firewall estaba bloqueando mi conexión a MYSQL. Después de que se quita la política de firewall para permitir la conexión, pude importar el esquema con éxito.
Sé que es viejo pero en mac
1. Control-click your connection and choose Connection Properties.
2. Under Advanced tab, set the Socket Timeout (sec) to a larger value.
Si experimenta este problema durante la restauración de un gran archivo de volcado y puede descartar el problema de que tiene algo que ver con la red (por ejemplo, la ejecución en el host local), mi solución podría ser útil.
Mi mysqldump contenía al menos un INSERT que era demasiado grande para que mysql lo computara. Puede ver esta variable escribiendo show variables like "net_buffer_length"; dentro de tu mysql-cli. Tienes tres posibilidades:
- aumentar net_buffer_length dentro de mysql -> esto necesitaría un reinicio del servidor
- create dump con
--skip-extended-insert, por insert one line -> aunque estos dumps son mucho más agradables de leer esto no es adecuado para grandes volcados> 1GB porque tiende a ser muy lento - crear volcado con insertos extendidos (que es el predeterminado) pero limitar net-buffer_length eg con
--net-buffer_length NR_OF_BYTESdonde NR_OF_BYTES es más pequeño que net_buffer_length del servidor -> Creo que esta es la mejor solución, aunque más lenta no se necesita reiniciar el servidor .
Utilicé el siguiente comando mysqldump: mysqldump --skip-comments --set-charset --default-character-set=utf8 --single-transaction --net-buffer_length 4096 DBX > dumpfile
Si su consulta tiene datos blob, este problema puede solucionarse aplicando un cambio my.ini como se propone en esta respuesta :
[mysqld]
max_allowed_packet=16M
Por defecto, esto será 1M (el valor máximo permitido es 1024M). Si el valor suministrado no es un múltiplo de 1024K, se redondeará automáticamente al múltiplo más cercano de 1024K.
Si bien el hilo de referencia es sobre el error 2006 de MySQL, la configuración de max_allowed_packet de 1M a 16M solucionó el error de 2013 que apareció cuando ejecutaba una consulta larga.
Para usuarios de WAMP: encontrará la bandera en la sección [wampmysqld] .
Si todas las otras soluciones aquí fallan, verifique su syslog (/ var / log / syslog o similar) para ver si su servidor se está quedando sin memoria durante la consulta.
Tuve este problema cuando innodb_buffer_pool_size se estableció demasiado cerca de la memoria física sin un archivo de intercambio configurado. MySQL recomienda una configuración de servidor específica de la base de datos innodb_buffer_pool_size a un máximo de alrededor del 80% de la memoria física , la configuré en alrededor del 90%, el kernel estaba eliminando el proceso de mysql. Se movió innodb_buffer_pool_size de vuelta a alrededor del 80% y eso solucionó el problema.
Solo realice una actualización de MySQL que reconstruirá el motor de innoDB junto con la reconstrucción de muchas tablas requeridas para el correcto funcionamiento de MySQL, como performance_schema , information_schema , etc.
Emita el siguiente comando desde su shell:
sudo mysql_upgrade -u root -p
Tengo el mismo problema al cargar un archivo .csv. Convirtió el archivo a .sql.
Usando el comando below, logro solucionar este problema.
mysql -u <user> -p -D <DB name> < file.sql
Espero que esto ayude.
Tuve el mismo problema, pero para mí la solución era un usuario de base de datos con permisos demasiado estrictos. Tuve que permitir la capacidad de Execute en la tabla mysql . Después de permitir que ya no tuviera conexiones caídas
Verifique si los índices están en su lugar primero.
SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = ''<schema>''
verificar sobre
OOM on /var/log/messages ,
modify innodb_buffer_pool_size value ; when load data , use 50% of os mem ;
Espero que esto ayude
SET @@local.net_read_timeout=360;
Advertencia: lo siguiente no funcionará cuando lo esté aplicando en conexión remota:
SET @@global.net_read_timeout=360;