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

Question

考虑以下场景:

3 个 EC2 实例位于:

美西

爱尔兰

东京

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

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

假设 6 个小时过去了，AWS 使该区域重新上线并且该服务器重新启动——我假设美国西部和东京将忽略爱尔兰的服务器，直到爱尔兰 CouchDB 服务器重新启动与两者的双向同步他们，啦啦:

爱尔兰 CouchDB _replicator 伪设置

复制[源=本地主机，目标=us-west]

复制[源=美国西，目标=本地主机]

复制[源=本地主机，目标=东京]

复制[源=东京，目标=本地主机]

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

Q2:如果网络故障在一小时后自行修复(特别是:没有服务器重启迫使数据库在启动时重新初始化)，相应的 CouchDB 实例对此有何 react ？我想 us-west 和 tokyo 会忘记爱尔兰，但爱尔兰会不会突然又开始和那两台服务器对话，重新初始化双向连续复制？

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

谢谢!

Answer 1

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

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

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