来自连接池的 "cleaned up" MySQL 连接是否可以安全删除？
Are "cleaned up" MySQL connections from a connection pool safe to delete?
考虑以下连接列表：
+----------+---------+------+------------------------+
| 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
我写完这个Whosebug之后post:
+----------+---------+------+------------------------+
| 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 |
+----------+---------+------+------------------------+
上下文:
这是一些第 3 供应商应用程序打开连接（我们无法获得源代码，因此我们不知道详细信息）。我们知道他们的连接管理很糟糕，他们也知道。这很糟糕，因为您可以在第一个 table - 90850182 中看到连接泄漏。如果其他人重置了他们的计时器，那么这一个就会开始无限老化。在旧版本的应用程序中，它将永远存在。在较新的版本中，它最终由供应商引入的 "patch" 捕获，它会在您指定的 x 秒后有效地清除连接。所以是 "a leak healing patch".
问题:
我们托管了数百个此类供应商应用程序，其中大多数具有超过 8 个连接，因为它们的流量更大。这导致我们必须维护令人厌恶的连接数量（谈论数千）。大约 80% 的连接处于 "cleaned up" 状态且持续时间不到 120 秒（最终由上述可配置的应用程序参数清除）。
这一切都由 Aurora RDS 处理，AWS 工程师告诉我们，如果应用程序没有正确关闭连接，标准 "wait_timeout" 将无法工作。好吧，"wait_timeout" 在 AWS Aurora 中变成了无用的装饰，但让我们在其他 thread/topic 中与 Jeff 一起使用它。
所以无论如何，我们在这个不起眼的应用程序上设置了来自第三方供应商的这个神奇的可配置参数，它控制陈旧连接的驱逐并且它有效。
题目：
立即驱逐处于 "cleaned up" 状态的连接是否安全？
目前这会在 120 秒后发生，这会导致大量此类连接。然而，在上面的 table 中，您可以看到计时器已重置，这意味着这些连接正在发生某些事情并且它们并非完全陈旧。 IE。应用程序的连接池 "touches" 以供进一步重用？
我不了解连接池的内部结构，就像从数据库中看到它们一样。一个连接池的所有保留连接默认都是"sleeping"处于"cleaned up"状态吗？
也就是说，如果你开始清理太多，你会积极地与连接池作斗争，创建更多的连接池来补充？
或者保留的连接有一些不同的状态？
即使您不完全理解上下文，我也希望经验丰富的 DBA 或连接池库维护者能够帮助解决此类问题。否则会弄脏我的手并最终自己回答这个问题，会尝试 apache 连接池，hikari，观察它们并尝试终止它们的空闲连接（模拟魔术参数）并尝试使用 0 秒魔术参数的第 3 方应用程序连接，看看它是否仍然有效。
感谢您的宝贵时间 :bow:.
答案
是的，来自 AWS 论坛 (https://forums.aws.amazon.com/thread.jspa?messageID=708499)
In Aurora the 'cleaned up' state is the final state of a connection
whose work is complete but which has not been closed from the client
side. In MySQL this field is left blank (no State) in the same
circumstance.
也来自同一个 post:
Ultimately, explicitly closing the connection in code is the best
solution here
根据我作为 MySQL DBA 的个人经验，并且知道 "cleaned up" 代表空白状态，我肯定会终止这些连接。
考虑以下连接列表：
+----------+---------+------+------------------------+
| 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
我写完这个Whosebug之后post:
+----------+---------+------+------------------------+
| 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 |
+----------+---------+------+------------------------+
上下文:
这是一些第 3 供应商应用程序打开连接（我们无法获得源代码，因此我们不知道详细信息）。我们知道他们的连接管理很糟糕，他们也知道。这很糟糕，因为您可以在第一个 table - 90850182 中看到连接泄漏。如果其他人重置了他们的计时器，那么这一个就会开始无限老化。在旧版本的应用程序中，它将永远存在。在较新的版本中，它最终由供应商引入的 "patch" 捕获，它会在您指定的 x 秒后有效地清除连接。所以是 "a leak healing patch".
问题:
我们托管了数百个此类供应商应用程序，其中大多数具有超过 8 个连接，因为它们的流量更大。这导致我们必须维护令人厌恶的连接数量（谈论数千）。大约 80% 的连接处于 "cleaned up" 状态且持续时间不到 120 秒（最终由上述可配置的应用程序参数清除）。
这一切都由 Aurora RDS 处理，AWS 工程师告诉我们，如果应用程序没有正确关闭连接，标准 "wait_timeout" 将无法工作。好吧，"wait_timeout" 在 AWS Aurora 中变成了无用的装饰，但让我们在其他 thread/topic 中与 Jeff 一起使用它。
所以无论如何，我们在这个不起眼的应用程序上设置了来自第三方供应商的这个神奇的可配置参数，它控制陈旧连接的驱逐并且它有效。
题目：
立即驱逐处于 "cleaned up" 状态的连接是否安全？
目前这会在 120 秒后发生，这会导致大量此类连接。然而，在上面的 table 中，您可以看到计时器已重置，这意味着这些连接正在发生某些事情并且它们并非完全陈旧。 IE。应用程序的连接池 "touches" 以供进一步重用？
我不了解连接池的内部结构，就像从数据库中看到它们一样。一个连接池的所有保留连接默认都是"sleeping"处于"cleaned up"状态吗？
也就是说，如果你开始清理太多，你会积极地与连接池作斗争，创建更多的连接池来补充？
或者保留的连接有一些不同的状态？
即使您不完全理解上下文，我也希望经验丰富的 DBA 或连接池库维护者能够帮助解决此类问题。否则会弄脏我的手并最终自己回答这个问题，会尝试 apache 连接池，hikari，观察它们并尝试终止它们的空闲连接（模拟魔术参数）并尝试使用 0 秒魔术参数的第 3 方应用程序连接，看看它是否仍然有效。
感谢您的宝贵时间 :bow:.
答案
是的，来自 AWS 论坛 (https://forums.aws.amazon.com/thread.jspa?messageID=708499)
In Aurora the 'cleaned up' state is the final state of a connection whose work is complete but which has not been closed from the client side. In MySQL this field is left blank (no State) in the same circumstance.
也来自同一个 post:
Ultimately, explicitly closing the connection in code is the best solution here
根据我作为 MySQL DBA 的个人经验，并且知道 "cleaned up" 代表空白状态，我肯定会终止这些连接。