MySQL Workbench在空闲时会断开连接。

Question

我正在使用MySQL Workbench 6.3来管理托管在Rackspace上的多个云数据库，我的操作系统是OS X 10.9.5。当我不活动超过5分钟时，会出现以下问题：

• 无法运行任何查询（错误代码2013：在查询期间丢失到MySQL服务器的连接）
• 尝试浏览数据库中的表时，会收到"无法获取表"、"无法获取视图"等消息
• 刷新左侧面板时，会提示"错误代码：2006 MySQL服务器已关闭"

因此，基本上连接已经断开了。这非常让人恼火，因为这只发生在5分钟的不活动之后。因此每次都需要关闭连接并重新打开。

我也尝试了这个：MySQL工作台：如何保持连接的活动状态，但没有改变任何东西。 在我的Workbench首选项标签中，我有以下设置：

• DBMS连接保持活动间隔时间（以秒为单位）：600
• DBMS连接读取超时时间（以秒为单位）：600
• DBMS连接超时时间（以秒为单位）：60

请注意，这个问题发生在确切的5分钟不活动之后！如果我在4'59分钟的时间间隔内运行两个查询，它完全正常工作。 此外，我的同事连接到相同的数据库时没有这个问题。有人有解决方法吗？

- Michel Y

---

听起来非常像是你本地机器的问题。如果WB在其他使用相同服务器的机器上工作正常，那么我会说这不是WB的问题。 - Mike Lischke

我也遇到了同样的问题，大约一周前才开始出现。你找到解决方法了吗？ - user3167249

在我从MySQL Workbench 6.0升级到6.3之后，同样的问题开始出现了。非常令人烦恼。 - Jeremy Goodell

在这里，我也遇到了相同的问题，使用的是WB 6.3.6 build 511版本的OSX。 - JFValdes

我也是。最后我降级回到6.0.x，那些“gone away”断开连接就停止了。我失去了太多的生产力。 - Fernando Piancastelli

Answer 1

前往“编辑”→“首选项”→“SQL编辑器”，您会看到：

DBMS connection keep-alive interval (in seconds): 600
DBMS connection read time out (in seconds): 600
DBMS connection time out (in seconds): 60

数据库管理系统连接保持活跃间隔是指Workbench向服务器发送保持活跃请求的频率。

由于5分钟等于300秒，设置DBMS连接保持活跃间隔 < 300（例如250）

这意味着“每250秒发送一次保持活跃请求”。 点击确定。

然后退出MySQL Workbench并重新启动它以使更改生效。

如果您使用标准TCP / IP通过SSH连接方法，则还可以配置ssh ServerAliveInterval。

- Kosh

---

感谢Kosh的回复。然而，我刚刚尝试了一下，仍然存在同样的问题。我仍然收到“错误代码：2013。在查询期间丢失与MySQL服务器的连接”的提示。您有其他解决方法吗？ - Michel Y

@Michel，抱歉忽略了您的评论。当查询处理时间超过DBMS连接读取超时时间时，会出现2013错误。您可以尝试增加读取超时时间或优化查询。 - Kosh

Answer 2

这个 bug 存在于 MySQL Workbench 6.0 之后的所有版本中（目前为止：6.1、6.2 和 6.3 都有该 bug）。

降级到 MySQL Workbench 6.0.x 看来是解决这个问题的唯一方法。

下载 MySQL Workbench 6.0.x：http://dev.mysql.com/downloads/workbench/6.0.html

- lepix

---

有报道吗？ - Antoniossss

在我看来，这才是实际上的正确答案。我使用了OP使用的版本，并尝试了我能在网上找到的每种组合方式，我还更新了设置中的超时变量。当我降级后，它就自动工作了（最终它捕捉到了我的超时变量）。 - Exitos

我也想知道这个。它是固定的吗？它会被修复吗？（例如，不是一个错误。） - posfan12

我至少在8中通过将保持连接时间设置为小于30秒（我将我的设置为15秒）来使其工作。 - Rahly

我成功地增加了Workbench 8.0中的超时时间，尽管在更改设置后，我不得不重新启动它才能生效。 - aero

Answer 3

FWIW: 根据Kosh的建议，我将设置更改如下，并且似乎已经解决了在Ubuntu 16上运行的WB 6.3中出现的问题：

DBMS connection keep-alive interval (in seconds): 60
DBMS connection read time out (in seconds): 60
DBMS connection time out (in seconds): 30

它可能有些过度，但它有效。

- Max

Answer 4

它通过在Windows Azure上托管的Ubuntu 14.04中将tcp_keepalive_time设置为120秒来解决了我的问题。Azure负载均衡器默认的TCP keepalive时间为240秒，如果Azure系统上的TCP keepalive时间大于此值，则可能会导致默默地断开连接。您应该将tcp_keepalive_time设置为120以改善此问题。

1.检查tcp_keepalive_time的值 cat /proc/sys/net/ipv4/tcp_keepalive_time 7200（默认为2小时）

2.将值从2小时更改为120秒。 sudo sysctl -w net.ipv4.tcp_keepalive_time=120

net.ipv4.tcp_keepalive_time = 120

3.更改后重新检查值。 cat /proc/sys/net/ipv4/tcp_keepalive_time 120

4.在sysctl文件中设置该值，以便即使重启后该值仍然保持不变。 vi /etc/sysctl.conf

按下 i 键（插入到文件中） net.ipv4.tcp_keepalive_time = 120（在文件底部添加此行） :wq（保存并退出）

- Srikanth P

Answer 5

这个问题困扰了我数月。我的连接是到一个Hostgator服务器。我能够连接并在连接后仅编辑表格10秒左右，然后我会进行表格提交，表格就会变成“只读”状态，并显示鼠标悬停消息：“无法确定唯一的行标识符（MySQL服务器已断开连接）”或“（在查询期间与MySQL服务器的连接丢失）”。

解决方案是，根据其他建议，减少保持连接时间。在我的情况下，必须将其降至10秒（显然，Hostgator对其带宽非常吝啬！）

首先，我尝试减少SSH KeepAlive（在“首选项/其他/超时”下），但这没有起作用。

关键是要减少DBMS连接保持活动间隔（在“首选项/SQL编辑器/MySQL会话”下）。我不得不把它降到10秒，直到连接保持稳定。您的主机可能不同。

最后，不再需要“全部刷新”，等待，做些事情，反复洗涤。

- SteveCinq

Answer 6

Kosh Very 是正确的答案。 对于无法使其正常工作的任何人，这里是另一种解决方案：

当我需要更改一个巨大的表（删除或添加列等）时，是通过终端运行查询：

1. 连接 ：mysql -u myusername -p

2. 会要求输入密码

3. 运行所需的长时间查询。 注意：在终端中编写查询需要为每个查询以分号（;）结尾。示例：ALTER TABLE mydb.mytable DROP COLUMN mycol;

- evilReiko

Answer 7

Kosh Very的答案对我没用，所以我找到了另一个解决方案：

修改my.ini文件中的max_allowed_packet。（路径：C:\ProgramData\MySQL\MySQL Server 5.6）

max_allowed_packet=16M

完成后重新启动MySQL服务。

- GorvGoyl

---

我的设置更大 - 或许你可以详细说明一下这个设置的重要性和原因。 - cerd