Mat*_*rth 6 mysql mysql-5.5 locking connectivity
在长时间运行的进程 (90m+) 中,我们的代码调用SELECT RELEASE_LOCK('..');
. 但是,Mysql has gone away
当我们这样做时,它总是会出现“ ”错误。
我们从来没有看到 ; 的返回值RELEASE_LOCK
。查询没有执行。在找到结果之前,我们失去了连接。
我们以前从未遇到过这个问题。这是在 Magento 1.12 升级到 1.13 之后
我们尝试了很多方法,包括增加各种超时,但都无济于事。您可能会建议什么是好的调试策略或可能导致此问题的东西?
对此最可能的解释是,假设您的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 分钟的流量到期计时器。
归档时间: |
|
查看次数: |
1953 次 |
最近记录: |