我们发现一个问题，网络中断后 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 的主服务器，这似乎解决了网络中断导致同步中断的问题。
原始问题中没有提到：我们可能会看到此问题，因为我们的副本分布在广泛的区域，跨越了许多不同的网络边界和不同类型和年龄的设备。