para - MySQL Workbench desconecta la conexión cuando está inactiva
mysql workbench ubuntu (7)
Este error existe en todas las versiones de MySQL Workbench más allá de 6.0 (en este momento: 6.1, 6.2 y 6.3 tienen el error).
La degradación a MySQL Workbench 6.0.x parece ser la única forma de solucionar este problema.
Descargue MySQL Workbench 6.0.x: http://dev.mysql.com/downloads/workbench/6.0.html
Estoy usando MySQL Workbench 6.3 en mi OS X 10.9.5 para administrar varias bases de datos en la nube (alojadas en Rackspace), y me sale el siguiente problema:
Cuando está inactivo durante 5 minutos, ocurren los siguientes problemas:
- No puedo ejecutar ninguna consulta (error 2013: conexión perdida al servidor MySQL durante la consulta)
- cuando intento explorar tablas en mi base de datos, recibo mensajes como "No se han podido obtener las tablas", "No se han podido obtener vistas", etc.
- al actualizar el panel izquierdo, aparece un "Código de error: el servidor MySQL 2006 se ha ido"
Entonces, básicamente, la conexión se ha ido.
Esto es realmente molesto ya que ocurre después de solo 5 minutos de inactividad. Por lo tanto, necesito cerrar la conexión y volver a abrirla cada vez.
También probé esto: MySQL Workbench: Cómo mantener viva la conexión , que no cambió nada. En la pestaña Preferencias de mi banco de trabajo, tengo la siguiente configuración:
- Intervalo de mantenimiento de la conexión DBMS (en segundos): 600
- Tiempo de espera de lectura de la conexión DBMS (en segundos): 600
- Tiempo de espera de conexión DBMS (en segundos): 60
Tenga en cuenta que este problema ocurre precisamente después de 5 minutos de inactividad. Si ejecuto dos consultas en un intervalo de 4''59 minutos, funciona perfectamente bien. Además, mis colegas que se conectan a la misma base de datos en su Workbench no tienen este problema.
¿Alguien tiene una solución para esto?
Esto me había vuelto mental durante meses. Mis conexiones fueron a un servidor Hostgator. Me conectaría y podría editar una tabla por solo 10 segundos más o menos después de conectarme, luego haría, digamos, una confirmación de tabla y la tabla cambiaría a "Solo lectura" con un mensaje de "No podría determinar un identificador de fila único (el servidor MySQL se ha ido) o "(perdió la conexión con el servidor MySQL durante la consulta).
La solución fue, como otras sugerencias aquí, para REDUCIR la configuración de mantener vivo. En mi caso, tenía que bajar a 10s (obviamente, Hostgator es bastante miserable con su ancho de banda).
Primero intenté reducir SSH KeepAlive (en Preferencias / Otros / Tiempos de espera ) pero esto no funcionó.
¿Qué hizo el truco fue reducir el DBMS connection keep-alive interval (en Preferencias / Editor de SQL / sesión de MySQL ). Tuve que llevarlo hasta 10 s hasta que la conexión se mantuviera estable. Tu anfitrión puede ser diferente.
Finalmente, no más "Refresh All", espere, haga algo, enjuague y repita.
FWIW: Siguiendo la recomendación de Kosh, cambié la configuración de la siguiente manera y parece haber eliminado el problema en WB 6.3 que se ejecuta en Ubuntu 16:
DBMS connection keep-alive interval (in seconds): 60
DBMS connection read time out (in seconds): 60
DBMS connection time out (in seconds): 30
Puede ser exagerado, pero funciona.
La respuesta de Kosh Very no funcionó para mí, así que encontré una solución diferente para esto:
cambie max_allowed_packet en el archivo
my.ini. (C: / ProgramData / MySQL / MySQL Server 5.6)max_allowed_packet = 16M
ahora reinicie el servicio MySQL una vez que haya terminado.
Me solucionó estableciendo tcp_keepalive_time en 120 segundos en Ubuntu 14.04 alojado en Windows Azure
El keepalive de TCP en el equilibrador de carga de Azure tiene 240 segundos de forma predeterminada, lo que puede ocasionar que caiga conexiones silenciosamente si el TCP keepalive en sus sistemas Azure es mayor que este valor. Debe establecer tcp_keepalive_time en 120 para mejorar este problema.
- Para verificar el tcp_keepalive_time
cat / proc / sys / net / ipv4 / tcp_keepalive_time
7200 (por defecto 2 horas)
2. establecer el valor de 2 horas a 120 segundos.
sudo sysctl -w net.ipv4.tcp_keepalive_time = 120
net.ipv4.tcp_keepalive_time = 120
- vuelva a verificar el valor después de cambiar.
cat / proc / sys / net / ipv4 / tcp_keepalive_time
120
4. Establezca el valor en el archivo sysctl para mantener el valor incluso después de reiniciar.
vi /etc/sysctl.conf
Presione i (Para insertar en el archivo) net.ipv4.tcp_keepalive_time = 120 (Agregue esta línea en la parte inferior del archivo): wq (Guardar y salir)
Vaya a Edición -> Preferencias -> Editor SQL y verá:
DBMS connection keep-alive interval (in seconds): 600
DBMS connection read time out (in seconds): 600
DBMS connection time out (in seconds): 60
El intervalo keep-alive de la conexión DBMS significa la frecuencia con la que Workbench envía una solicitud keep-alive al servidor para mantener la conexión activa.
Desde 5 minutos == 300 segundos, configure el intervalo de mantenimiento de conexión de DBMS <300 (por ejemplo, 250)
Significará "enviar solicitud de mantener vivo cada 250 segundos". Haga clic en Aceptar.
A continuación, salga de MySQL Workbench y reinícielo para que los cambios entren en vigencia.
Si usa TCP / IP estándar sobre el método de conexión SSH, también puede ser útil configurar ssh ServerAliveInterval también.
Kosh Very es la respuesta correcta. Para cualquiera que no pueda hacer que funcione, aquí hay otra solución:
Donde necesito alterar una tabla enorme (colocar o agregar una columna o algo así), es ejecutar la consulta (s) por terminal:
Conectar :
mysql -u myusername -pSe le pedirá una contraseña
- Ejecute la (s) consulta (s) larga (s) que necesita. Nota: escribir una consulta en el terminal requiere un punto y coma (;) final para cada uno. Ejemplo:
ALTER TABLE mydb.mytable DROP COLUMN mycol;