从连接池中“清理”的 MySQL 连接是否可以安全删除？答案

【问题标题】：Are "cleaned up" MySQL connections from a connection pool safe to delete?从连接池中“清理”的 MySQL 连接是否可以安全删除？
【发布时间】：2020-06-10 17:40:29
【问题描述】：

考虑以下连接列表：

+----------+---------+------+------------------------+
| ID       | COMMAND | TIME | STATE                  |
+----------+---------+------+------------------------+
| 87997796 | Sleep   |   15 | cleaned up             |
| 90850182 | Sleep   |  105 | cleaned up             |
| 88009697 | Sleep   |   38 | delayed commit ok done |
| 88000267 | Sleep   |    6 | delayed commit ok done |
| 88009819 | Sleep   |   38 | delayed commit ok done |
| 90634882 | Sleep   |   21 | cleaned up             |
| 90634878 | Sleep   |   21 | cleaned up             |
| 90634884 | Sleep   |   21 | cleaned up             |
| 90634875 | Sleep   |   21 | cleaned up             |
+----------+---------+------+------------------------+

在不到一分钟的短时间内：

+----------+---------+------+------------------------+
| ID       | COMMAND | TIME | STATE                  |
+----------+---------+------+------------------------+
| 87997796 | Sleep   |    9 | cleaned up             |
| 88009697 | Sleep   |   32 | delayed commit ok done |
| 88000267 | Sleep   |    9 | delayed commit ok done |
| 88009819 | Sleep   |   31 | delayed commit ok done |
| 90634882 | Sleep   |   14 | cleaned up             |
| 90634878 | Sleep   |   14 | cleaned up             |
| 90634884 | Sleep   |   14 | cleaned up             |
| 90634875 | Sleep   |   14 | cleaned up             |
+----------+---------+------+------------------------+
8 rows in set (0.02 sec)
enter code here

在我写完这篇 stackoverflow 帖子后：

+----------+---------+------+------------------------+
| ID       | COMMAND | TIME | STATE                  |
+----------+---------+------+------------------------+
| 87997796 | Sleep   |    0 | cleaned up             |
| 88009697 | Sleep   |   53 | delayed commit ok done |
| 88000267 | Sleep   |    0 | delayed commit ok done |
| 88009819 | Sleep   |   52 | delayed commit ok done |
| 90634882 | Sleep   |    5 | cleaned up             |
| 90634878 | Sleep   |    5 | cleaned up             |
| 90634884 | Sleep   |    5 | cleaned up             |
| 90634875 | Sleep   |    5 | cleaned up             |
+----------+---------+------+------------------------+

上下文：

这是第三个供应商应用打开连接（源代码对我们不可用，所以我们不知道细节）。我们知道他们的连接管理很糟糕，他们也知道这一点。这很糟糕，因为您可以在第一个表中看到连接泄漏 - 90850182。如果其他人重置了他们的计时器，那么这个计时器就会开始无限老化。在旧版本的应用程序中，它将永远存在。在较新的版本中，它最终被供应商引入的“补丁”捕获，该补丁在您指定的 x 秒后有效地清除连接。所以它是“一个泄漏修复补丁”。

问题：

我们托管了数百个此类供应商应用程序，其中大多数具有超过 8 个连接，因为它们的流量更大。这导致我们必须维持令人作呕的数量（说数千个）连接。大约 80% 的连接处于“已清理”状态并且不到 120 秒（最终由上述可配置的应用程序参数清理）。

这一切都由 Aurora RDS 处理，AWS 工程师告诉我们，如果应用程序没有正确关闭连接，标准的“wait_timeout”将无法正常工作。好吧，“wait_timeout”在 AWS Aurora 中成为无用的装饰，但让我们在其他线程/主题中与 Jeff 一起使用。

因此，无论如何，我们在这个不起眼的应用程序上设置了来自第三方供应商的这个神奇的可配置参数，该参数控制陈旧连接的逐出并且它可以工作。

问题：

立即驱逐处于“已清理”状态的连接是否安全？

目前这种情况发生在 120 秒后，这会导致大量此类连接。然而，在上面的表格中，您可以看到计时器已重置，这意味着这些连接正在发生某些事情并且它们并非完全陈旧。 IE。应用程序的连接池“接触”它们以供进一步重用？

我不知道如何从数据库中看到连接池的内部知识。连接池的所有保留连接是否默认都处于“已清理”状态“休眠”？

所以说如果你开始清理太多，你会积极争取连接池创建更多来补充？

或者保留的连接有一些不同的状态？

即使您不完全了解上下文，我也希望资深 DBA 或连接池库维护人员能够帮助解决此类问题。否则会弄脏我的手并最终自己回答这个问题，会尝试 apache 连接池，hikari，观察它们并尝试杀死他们的空闲连接（模拟魔术参数）并尝试使用 0 秒魔术参数连接这个 3rd 方应用程序，看看它是否仍然有效。

感谢您的时间：鞠躬：。

【问题讨论】：

这似乎更像是一个 dba 问题/服务器。当您的网站被上帝编程时，只有连接才会打开，只要您的 wenbsite 没有关闭它或超过 mysql 连接等待超时。连接池会回收它们，请参阅stackoverflow.com/questions/4284194/…
连接池被高估了。有没有限制连接数的配置？将它调低到 0 或 1。
我无法限制连接数，因为第 3 方应用程序将停止工作并返回 500 吐出连接被拒绝。

标签： mysql database-connection connection-pooling amazon-aurora

【解决方案1】：

答案

是的，来自 AWS 论坛 (https://forums.aws.amazon.com/thread.jspa?messageID=708499)

在 Aurora 中，“清理”状态是连接的最终状态其工作已完成但尚未从客户那里关闭边。在 MySQL 中，此字段保留为空白（无状态）情况。

也来自同一个帖子：

最终，在代码中显式关闭连接是最好的解决办法在这里

根据我作为 MySQL DBA 的个人经验，并且知道“已清理”代表空白状态，我肯定会终止这些连接。

【讨论】：