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

Question

考虑以下连接列表：

+----------+---------+------+------------------------+
| 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工程师告诉我们，如果应用程序不能正确关闭连接，标准的“等待超时”将无法工作。“等待超时”在AWS Aurora中变成了无用的装饰，但让我们在其他线程/主题中与Jeff一起讨论。

所以不管怎样，我们有这个神奇的可配置参数从第三方供应商设置在这个晦涩的应用程序，它控制驱逐陈旧的连接，它的工作原理。

问题是：

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

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

我不知道连接池的内部结构，也不知道它们是如何从数据库中看到的。默认情况下，连接池的所有保留连接都处于“已清理”状态吗？

所以说，若你们开始清理太多，你们会积极地对抗连接池，创造更多的补充？

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

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

感谢你的时间：鞠躬：。

Answer 1

答案

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

在Aurora中，“清理”状态是工作已完成但尚未从客户端关闭的连接的最终状态。在MySQL中，在相同的情况下，此字段留空（无状态）。

同样来自同一职位：

最终，在代码中显式关闭连接是最好的解决方案

从我作为MySQL DBA的个人经历来看，知道“清理”代表空白状态，我肯定会杀死那些连接。