简短回答:

空闲超时既是标准的,也是必需的(尽管您可以修改它,请参见此处: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-tcp-idle-timeout )。也就是说,对于从负载平衡器IP向外传输的任何流量,没有办法完全消除这种情况。当前支持的最长持续时间为30分钟。

因此,根据最初的问题,处理这个问题的最佳方法(我觉得)是将超时时间保持在4分钟(因为它无论如何都必须存在),然后在达到负载平衡器超时之前,设置基础设施以优雅的方式断开连接(空闲时)。

对于我们的Ghost博客(它访问了一个MySQL数据库),我能够像上面提到的那样回滚,这使得Ghost进程能够处理DB断开/重新连接的场景。

是的。同样的问题。

https://github.com/pgbouncer/pgbouncer )作为我们集群中的另一个容器,可以通过以下指南找到: https://github.com/edoburu/docker-pgbouncer/tree/master/examples/kubernetes/singleuser

通常,任何试图从AKS访问远程数据库的人都可能需要实现一个中间连接池解决方案。池服务位于中间(PGBOUNCESS为我们),并跟踪多久连接一直闲置,使您的工人进程不需要关心这一点。

如果您开始接近负载平衡器超时,连接池服务将抛出旧连接并创建新连接(重置计时器)。这样,当您的客户机通过管道发送数据时,它会像预期的那样到达数据库服务器。

这是一个非常令人沮丧的错误/案例。我们花了至少两天的时间来找出第一个解决方案,但即使知道这可能是同一个问题,这次我们又花了两天时间。

即使将计时器延长到超过4分钟的默认值,也不会有真正的帮助,因为这只会让问题更容易解决。我想我只是希望那些在从Azure AKS/Kubernetes连接到远程数据库时遇到困难的人比我更擅长谷歌搜索,并能为自己省去一些痛苦。