应用侧已销毁连接仍被MaxScale保留导致连接数超限问题咨询

• 核心原因是前端客户端连接（Hikari到MaxScale的连接）没有配置自动回收规则：你注释了服务段的connection_timeout配置项，MaxScale默认不会主动断开空闲的前端连接，即使应用进程停止，部分半开连接或者未正常触发关闭逻辑的连接会一直被计入max_connections的配额统计中。当你重启应用时，Hikari会新建20个新连接，此时旧的20个连接仍被占用，总连接数超过你配置的20阈值，就会触发超限报错。
• 你配置的persistpoolmax=0、persistmaxtime=60仅作用于MaxScale到后端MySQL的持久连接池，和前端Hikari到MaxScale的连接生命周期没有关系，因此无法解决前端连接残留的问题。

• 恢复服务段的connection_timeout配置，建议数值比Hikari侧的idleTimeout配置大10~30秒即可：比如Hikari的空闲连接超时设为600秒，MaxScale的connection_timeout可以设为630秒，既可以保证空闲连接被及时回收，也不会出现MaxScale提前断开Hikari正在使用的连接的问题。
• 你的persistpoolmax=0配置符合预期（禁用MaxScale后端持久连接池，交由Hikari全权管理连接生命周期），不需要调整。
• 快速验证方案：可以临时将connection_timeout设为30秒，停止应用后等待30秒再重启，观察是否还会出现连接超限错误，即可确认问题根因。

内容的提问来源于stack exchange，提问作者alubin