CouchDB Replication如何与失败/恢复服务器一起运行？

Question

请考虑以下情形:

3个EC2实例位于:

• US-WEST
• 爱尔兰
• 东京

每个实例都是专用的CouchDB服务器.每个CouchDB服务器都设置为与每个其他服务器(双向)运行连续复制.

现在假设由于某些AWS中断,Ireland服务器脱机.US-WEST和Tokyo CouchDB服务器将重试X次,然后最终无法使用该服务器进行复制(这是正确的吗？)

让我们说6个小时过去,AWS让该地区重新上线,该服务器重新启动 - 我认为US-WEST和东京将忽略爱尔兰的服务器,直到爱尔兰CouchDB服务器重新启动与两者的双向同步他们,一个la:

Irish CouchDB _replicator Pseudo-Settings

• 复制[源=本地主机,目标= US-西]
• 复制[源=我们走向,目标=本地主机]
• 复制[源=本地主机,目标=东京]
• 复制[源=东京,目标=本地主机]

Q1:我对Couch复制失败/恢复的理解是否正确？

Q2:如果网络故障在一小时后自行修复(具体是:没有服务器重启,迫使数据库在启动时重新启动),该怎么做各个CouchDB实例对此做出反应怎么办？我想我们西方和东京会忘记爱尔兰,但是爱尔兰是否会突然再次与这两台服务器交谈,重新初始化双向连续复制？

我对EC2环境中的故障​​恢复特别感兴趣,所以如果我错过了该环境的具体细节,请告诉我.

谢谢!

Answer 1

在 1.1 之前，复制任务不是持久的，甚至是连续的。如果发生断开连接，重试的次数有限，但最终会停止。当连接恢复时，您将需要再次启动复制。由于复制是幂等的（启动相同的复制任务两次与启动一次相同），您只需添加一个 cronjob 来每分钟启动一次（或者您认为合理的任何时间间隔）。如果任务已在运行，则尝试返回成功（但不会启动另一个复制）。

在1.1中，您可以通过在特殊的_replicator数据库中创建文档来创建持久复制任务。如果CouchDB崩溃或连接中断，它将重试此操作。注意：1.1.0最终放弃，在下一个版本（1.1.1）中我们允许无限重试。

由于 CouchDB 是从一开始就支持多主复制而设计的，因此当您听说它能够很好地处理连接中断时，您不会感到惊讶。中断期间发生的变化会被快速发现并复制。