mysql_ping 与 Amazon RDS 一起挂起

Posted 2023-02-27

【中文标题】mysql_ping 与 Amazon RDS 一起挂起

【英文标题】：mysql_ping hangs with Amazon RDS

【发布时间】：2014-01-18 08:17:43

【问题描述】：

我正在尝试从在外部 ubuntu 服务器上运行的 php 工作人员与 mysql RDS 数据库建立持久连接。作为连接的一部分，我首先检查“mysql_ping”。如果 ping 返回 true，则使用当前连接，否则建立新连接。

我面临的问题是，当我启动我的工作人员时，连接建立良好，并且可以正常工作一段时间，即我可以成功地对 RDS 数据库进行重复查询。但是大约 15 分钟后，如果我发出请求，那么“mysql_ping”会挂起，因此 php 脚本本身也会挂起。在进一步调试中，我发现 mysql_ping 响应在 936 秒后返回为 false。

从外部服务器访问 db 所需的权限在那里，并且在这段时间内（脚本挂起时），我能够使用 mysql 命令行选项成功连接到 RDS 数据库。另外，如果我杀死worker并重新启动它，它可以再次成功连接，但问题在15分钟左右后再次出现。

RDS 服务器设置中是否需要更改任何内容以避免此问题？

问候， 卡皮尔

【参考方案1】：

我在文档中找不到引用，但我的经验表明，一般来说 EC2 的网络基础设施（其中可能包括 RDS 以及可能在按客户配置的虚拟机上运行的任何其他 AWS 服务，如果并非所有 AWS，当然似乎也不严格限于“EC2 实例”）实施状态数据包检查，并且会在几分钟的绝对空闲后“忘记”TCP 连接是有效的......导致您的行为描述。

连接两端的机器可能会确信连接仍然存在，但网络不允许流量在它们之间传递，因为 SPI 环境中的 TCP 会话未被发现，它们被创建，并且只能在网络一开始就看到连接时创建（SYN, SYN/ACK, ACK）。我最初在 EC2（不是 RDS）中的 MySQL 服务器上遇到了这个问题，但如果根本原因不一样，我会感到非常惊讶。

有两种可能的方法来解决这个问题。

如果您的 PHP 机器是 Linux，请配置内核以在第 4 层保持连接活动。此更改对您来说是不可见的，因为这些保持活动不会更改 @987654327 中 Time 列中的值@ 用于Sleep 中的连接，因为它不会重置连接在第 7 层空闲的时间量......但如果管理 MySQL 连接的库正在设置套接字选项，它应该避免来自 AWS 基础设施的超时正确地利用它。

http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html 解释了如何实时设置，以及如何使其在重新启动后保持不变。

如果做不到这一点，另一种选择是强制 MySQL 在网络超时之前关闭连接，以便 PHP 机器立即识别出它正在尝试在关闭的套接字上进行通信。缩短超时而不是延长超时可能听起来违反直觉，但是如果会话空闲时间过长，缩短超时应该会导致您的 ping 测试很快失败，这也（本质上）“解决”了问题，假设理智在 PHP 客户端库中。一旦您的应用程序更忙，连接可能很少会空闲足够长的时间来达到超时。

MySQL 服务器有两种不同的空闲超时设置：wait_timeout（用于非交互式会话，即来自代码的连接，如 PHP）和interactive_timeout（来自查询浏览器和命令行客户端）但服务器只知道区别是因为客户端库必须通知服务器它正在建立哪种类型的连接。假设您的客户端库使用正确的设置，那么wait_timeout 就是您要寻找的那个。如果更改 Linux 内核中的 TCP keepalive 设置没有改变，将其设置为低于 900 的值应该可以解决问题。但请注意，在进行更改后，只有未来的连接会受到影响——在进行更改时已经建立的连接仍将以当前值运行，默认值为 8 小时（28800 秒）。这些可在您的实例的 RDS 参数组中进行配置。

有hints of similar behavior in the AWS docs here，以及需要调整的 Windows 注册表设置以更改 TCP keepalives 如果您在 Windows 上运行 PHP 服务器，而不是我上面假设的 Linux...即使文章特别是关于 Redshift 和 EC2 外部的连接，它似乎仍然可以验证上面讨论的潜在问题。

【讨论】：

嗨迈克尔.....非常感谢详细而详尽的回复。您的指针非常有用。我正在使用 Linux 服务器....让我今天尝试其中的一些东西，然后重新开始。顺便说一句....祝你新年快乐:)

嗨迈克尔......你的解决方案工作得非常好......非常感谢你的见解......我自己永远不会想到它！