CouchDB 复制如何处理故障/恢复的服务器？

Question

考虑以下场景：

3 个 EC2 实例位于：

• 美国西部
• 爱尔兰
• 东京

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

现在假设爱尔兰服务器由于某些 AWS 中断而离线。 US-WEST 和 Tokyo CouchDB 服务器将重试 X 次，然后最终与该服务器的复制失败（这是正确的吗？）

假设 6 小时过去了，AWS 使该区域重新上线，并且该服务器恢复正常 - 我假设 US-WEST 和东京将忽略爱尔兰的服务器直到爱尔兰 CouchDB 服务器重新- 启动与它们的双向同步，a la：

爱尔兰 CouchDB _replicator 伪设置

• 复制[source=localhost,target=us-west]
• 复制[source=us-west,target=localhost]
• 复制[source=localhost,target=tokyo]
• 复制[source=tokyo,target=localhost]

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

Q2：如果网络故障在一小时后自行修复（具体而言：没有服务器重启迫使数据库在启动时重新初始化），各个 CouchDB 实例对此有何反应？我想 us-west 和 tokyo 会忘记爱尔兰，但爱尔兰会突然开始再次与这两台服务器对话，重新初始化双向连续复制吗？

我对 EC2 环境中的故障​​恢复特别感兴趣，所以如果我遗漏了该环境的特定细节，请告诉我。

谢谢！

Answer 1

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

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

由于 CouchDB 的设计初衷就是支持多主复制，因此听到它可以很好地处理连接中断时，您不会感到惊讶。中断期间发生的更改会被快速找到并复制。