PHP/Mysqli 缓存 mysql 主机？不尊重低 TTL

Question

我们在 AWS 上使用 PHP 以及 RDS/Aurora。

这通过公开集群的端点来实现，该端点是当前事件 mysql 节点的 CNAME 记录。

当我们添加/删除读取器节点时，在发生故障转移的情况下，此端点会自动更新，TTL 为 5 秒。

因此，我们的应用程序应该非常快速地发现并响应新节点。

我们注意到，故障转移后，“Mysql 已消失”的时间比 5 秒的时间长得多。我们遇到过这种情况长达 30 分钟的情况，此时我们重新启动了 Apache，问题就得到了解决。

似乎在应用程序的某个地方，数据库没有查询端点 DNS 并解析新端点，因此仍然指向不再存在的节点。

我们确实使用持久连接(为了性能)，这是明显的罪魁祸首，但是我们随后在关闭这些连接的情况下进行了测试，并且存在相同的行为。

我们使用 PHP 7.1 和 Mysqli。我们在 mysqli 连接周围有一个单例类，但即使这保持相同的连接打开，它也只会持续执行单个脚本的时间，通常是几毫秒。

关于缓存可能发生在哪里的任何指导？

Answer 1

目前尚不清楚您的问题是否与远程服务上的 DNS 相关或与您自己的 (AWS) 本地网络/服务上的缓存相关。这是首先要考虑的事情。

据我所知，Linux 不会缓存 DNS 查找，Apache/PHP 也不会(除非您使用 mod_proxy，在这种情况下请查看 disablereuse Off 设置)。考虑到这一点，我预计您的 Apache 服务重新启动导致其开始工作可能是巧合。

我的第一个建议是强制进行故障转移，然后立即检查来自多个不同地理位置的名称服务器并使用 AWS 服务器上的终端来查看相同的时间服务器报告更新的结果。名称服务器很可能只是忽略您的 TTL，或者可能只是“将其视为建议”。

总而言之，DNS TTL 只是解析名称服务器缓存多长时间的建议。没有什么可以强制名称服务器实际遵守您设置的内容。现实情况是，许多名称服务并不完全遵循您的设置，甚至根本不遵循您的设置。

如果名称服务器在其他地方的更新速度与预期一样快，但不是在您的 AWS 服务器上，并且 mysql 仍然无法连接；这表明缓存在您的服务器上的某个位置或更可能在AWS网络中。除非缓存直接在您的服务器上(如上所述，我认为这是不可能的)，否则我怀疑您对此能做很多事情。

最终更新 DNS 记录并使用低 TTL 作为故障转移解决方案可能永远无法实现一致的 <1 分钟故障转移速度。

您可能想研究替代方法，例如 ClusterControl或代理方法，例如 ProxySQL .