![网络中断后 OpenLDAP syncrepl 无法恢复](https://linux22.com/image/757221/%E7%BD%91%E7%BB%9C%E4%B8%AD%E6%96%AD%E5%90%8E%20OpenLDAP%20syncrepl%20%E6%97%A0%E6%B3%95%E6%81%A2%E5%A4%8D.png)
我们发现一个问题,网络中断后 syncrepl 无法恢复。
环境:
- Centos 7 副本
- OpenLDAP 2.4.44(-21.el7_6)
- 日志级别设置为
comm sync
(不产生任何有用的信息) - 同步配置:
syncrepl rid=113 provider="ldap://ldap.example.com" type=refreshAndPersist retry="60 +" searchbase="dc=example,dc=com" sizelimit=unlimited bindmethod=simple starttls=critical tls_reqcert=allow binddn="cn=Replicator,dc=example,dc=com" credentials="supersecretpassword" updateref ldap://ldap.example.com
我们监控的 LDAP 服务的一个方面是所有生产副本的时效性和一致性。cron 作业使用当前 Unix 纪元在主服务器上易于查询的属性中更新“金丝雀记录”。通过比较副本的纪元与金丝雀记录的纪元,定期监控副本的时效性。如果差异超过 10 分钟,我们会收到通知。
我们有几个副本,据我们所知,偶尔会出现短暂的网络中断。不幸的是,我们对这个问题的了解有限:我们怀疑此时,这就是这些副本偶尔无法通过时效性测试的原因。发生这种情况时,副本将继续无法通过测试——它们将无法同步——直到重新启动 slapd。尽管设置retry="60 +"
应该每 60 秒重试一次同步,但情况仍然如此。
通过创建防火墙规则删除来自主服务器的任何流量,可以在任何副本上重现此问题。我创建了两条规则:一条是删除所有流量到主用,以及丢弃所有流量的从主服务器。等待一段时间(不确定要等多久,我通常会切换任务直到收到第一个通知),然后移除防火墙阻止。同步永远无法恢复。
我发现阻止规则上的数据包计数器为 0 个来自副本的数据包到主服务器到副本服务器的延迟大于 0。这与 syncrepl 的预期“推送”行为相匹配,但我们预计副本服务器会以某种方式重试连接。
副本保留与主副本的传出连接。
我相信使用keepalive
,或者,如果所有其他方法都失败了,refreshOnly
将为我们解决货币问题,但令人惊讶的是,像这样偶尔的网络中断可能会导致同步冻结,我认为这是一个非常标准的配置(refreshAndPersist 示例不包括或推荐使用keepalive
)。
有人能建议这里应做出的最佳改变吗?
答案1
我已经keepalive="360:60:60"
在我们的副本上进行了测试。据我所知,这是处理此问题的最佳方法。
测试方式与重现原始问题的方式相同。我确实注意到,在针对在 CentOS 7 上运行的测试主服务器进行测试时,问题并未在测试的时间范围内发生 - 无论设置如何,连接都会恢复keepalive
。我还没有调查这是为什么。无论如何,我们目前在生产中有一个运行 CentOS 6 的主服务器,这似乎解决了网络中断导致同步中断的问题。
原始问题中没有提到:我们可能会看到此问题,因为我们的副本分布在广泛的区域,跨越了许多不同的网络边界和不同类型和年龄的设备。