对等连接重置-在k8s集群上使用驱动程序2.8.0和mongo 4.0.9

时间:2019-06-24 09:29:15

标签: mongodb mongodb-.net-driver amazon-eks

在我们的设置中,我们一直收到“对等连接重置” mongo错误。 设置说明:

  • mongo作为副本集在EKS上的k8s集群中运行
  • 在EKS上的同一k8s集群中运行的客户端(C#)
  • mongo 4.0.9
  • C#驱动程序2.8.0
  • 连接池已打开
  • 最大空闲时间设置为10分钟(默认为10秒)
  • 最大连接寿命设置为10分钟(默认覆盖10s)

我们收到这些错误。我们观察到,如果存在一系列调用,例如500个调用以执行基于键的选择,则没有问题。 然后我们暂停5分钟,然后重复测试,这是我们第一次收到“对等方重置连接”的信息。稍后,测试将继续。 每次暂停后都会发生这种情况。

这种情况会随着真实用户的行为而重复发生,可能会突然出现活动,然后停顿下来。结果,我们在业务工作流的关键部分不断获得“对等连接重置”。在客户端,解决方案是执行防御性编码并重复呼叫,但这在许多地方都是一个变化。

尝试其他组合:

  • mongo 4.0.9
  • C#驱动程序2.8.0
  • 连接池已打开
  • 最大闲置时间120min
  • 最长连接寿命60分钟

但是行为没有改变。

在我们看来,虽然在服务器端关闭了TCP连接,但是客户端仍然认为这是有效连接,并尝试使用它,从而导致此错误。

还有其他人遇到过这种情况吗?任何建议将不胜感激,如有需要,我们乐意提供更多信息。

1 个答案:

答案 0 :(得分:1)

在AKS上运行的集群有一个非常相似的问题。我设法将其追溯到conntrack看到(或认为正在看到)tcp重传。这是一个示例,其中客户端pod为10.3.0.8,服务器pod为10.3.0.113,查看运行mongo的节点上的conntrack条目:

conntrack -L|grep "10\.3\.0\.113"|grep "10\.3\.0\.88"

conntrack v1.4.3 (conntrack-tools): 1091 flow entries have been shown.
tcp      6 86398 ESTABLISHED src=10.3.0.88 dst=10.3.0.113 sport=34919 dport=27017 src=10.3.0.113 dst=10.3.0.88 sport=27017 dport=34919 [ASSURED] mark=0 use=1
tcp      6 86398 ESTABLISHED src=10.3.0.88 dst=10.3.0.113 sport=33389 dport=27017 src=10.3.0.113 dst=10.3.0.88 sport=27017 dport=33389 [ASSURED] mark=0 use=1
tcp      6 86390 ESTABLISHED src=10.3.0.88 dst=10.3.0.113 sport=39917 dport=27017 src=10.3.0.113 dst=10.3.0.88 sport=27017 dport=39917 [ASSURED] mark=0 use=1
tcp      6 51 TIME_WAIT src=10.3.0.88 dst=10.3.0.113 sport=36649 dport=27017 src=10.3.0.113 dst=10.3.0.88 sport=27017 dport=36649 [ASSURED] mark=0 use=1
tcp      6 298 ESTABLISHED src=10.3.0.88 dst=10.3.0.113 sport=35033 dport=27017 src=10.3.0.113 dst=10.3.0.88 sport=27017 dport=35033 [ASSURED] mark=0 use=1
tcp      6 299 ESTABLISHED src=10.3.0.88 dst=10.3.0.113 sport=44131 dport=27017 src=10.3.0.113 dst=10.3.0.88 sport=27017 dport=44131 [ASSURED] mark=0 use=1

您可以看到有些条目的超时时间很短(298/299秒)-它们以86400秒(/ proc / sys / net / netfilter / nf_conntrack_tcp_timeout_建立)开始,但已移至300秒(nf_conntrack_tcp_timeout_max_retrans) 。我可以肯定地是这种情况,因为更改nf_conntrack_tcp_timeout_max_retrans会更改上面的超时值。

我目前不知道为什么会发生重传,但是知道您的问题是否相同很有趣。

对于我来说,可以通过将nf_conntrack_tcp_timeout_max_retrans增加到> 10分钟,或将mongo空闲连接超时减少到<5分钟来解决。