CouchDB复制在失败/恢复的服务器中的行为如何？

Question

考虑以下情况：

3个EC2实例位于：

• US-WEST
• Ireland
• Tokyo

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

现在假设爱尔兰服务器由于AWS中断而脱机。美国-西方和东京的CouchDB服务器将重试X次，然后最终失败与该服务器的复制(这是正确的吗？)

假设6个小时过去了，AWS使该地区恢复联机，而该服务器恢复--我猜想美国西部和东京将忽略爱尔兰的服务器，直到爱尔兰的CouchDB服务器重新启动与它们的双向同步，a la：

爱尔兰CouchDB _replicator伪设置

• replicatesource=localhost，target=us-west
• replicatesource=us-west，target=localhost
• replicatesource=localhost，target=tokyo
• replicatesource=tokyo，target=localhost

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

Q2:如果一个小时后出现网络故障(具体而言:没有服务器重新启动，迫使DB在启动时重新登录)，那么相应的CouchDB实例对此有何反应？我想美国西部和东京会忘记爱尔兰，但爱尔兰会突然开始与这两台服务器对话，重新初始化双向的连续复制吗？

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

谢谢!

Answer 1

在1.1之前，复制任务是不持久的，甚至是连续的。在断开连接的情况下，尝试重试的尝试有限，但最终会停止。当连接恢复时，您将需要再次启动复制。由于复制是幂等的(启动相同的复制任务两次与启动一次相同)，所以您可以添加一个cron作业来每分钟启动它(或者任何对您来说正常的时间间隔)。如果任务已经运行，则尝试返回成功(但不会启动其他复制)。

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

由于CouchDB是自始至终为支持多主复制而设计的，因此您不会惊讶地听到它很好地处理连接的中断。中断期间发生的更改将迅速找到并复制。