SELECT RELEASE_LOCK 导致“Mysql 已经消失”

Question

在长时间运行的进程 (90m+) 中，我们的代码调用SELECT RELEASE_LOCK('..');. 但是，Mysql has gone away当我们这样做时，它总是会出现“ ”错误。

我们从来没有看到 ; 的返回值RELEASE_LOCK。查询没有执行。在找到结果之前，我们失去了连接。

我们以前从未遇到过这个问题。这是在 Magento 1.12 升级到 1.13 之后

我们尝试了很多方法，包括增加各种超时，但都无济于事。您可能会建议什么是好的调试策略或可能导致此问题的东西？

Answer 1

对此最可能的解释是，假设您的wait_timeout系统变量没有设置得太低，网络硬件的中间件正在拆除或“忘记”您的空闲 TCP 连接。

状态防火墙维护所有当前“流”的内部数据结构——源/目标地址/端口四元组——如果流没有流量太长时间，流的记录就会从防火墙的内存中删除。下一个到达的 TCP 数据包与任何已建立的流都不匹配，并且没有SYN设置标志，因此它不是新连接，防火墙认为它无效并丢弃它或欺骗RST来自目的地的数据包。

例如，您很可能会在任何查询中遇到相同的错误SELECT NOW();，一旦连接完全空闲太长时间，可能会返回相同的结果。请注意，运行查询不会阻止连接在 TCP 层处于“空闲”状态。

同时，连接可能不会从进程列表中消失，因为由于它完全空闲，服务器不会发送任何内容，因此不会意识到在网络上的某个点，它是无效的 TCP 连接。

在我的经验中，这只是在 Amazon EC2 中发生的一个例子。

解决方法是至少在连接的一端在操作系统本身中启用 TCP keepalive。这将导致主机在空闲时间继续交换 TCP 流量，即使连接上没有有效负载。启用这些应该可以调解这个问题。

Linux：http : //tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html

Windows：https : //technet.microsoft.com/en-us/library/cc957549.aspx

如果好奇，那么您还应该通过反复试验，发现空闲连接在一段时间后不再可用……例如，连接闲置 14 分钟可能没问题，但连接闲置了16 分钟将永远是死的，这表明防火墙有一个 15 分钟的流量到期计时器。