Amazon ec2 CouchDB复制在发生故障/恢复的服务器上的行为如何？

考虑以下场景：

3个EC2实例位于：

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

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

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

假设6个小时过去了，AWS恢复了该地区的在线状态，服务器也恢复了——我假设美国西部和东京会忽略爱尔兰的服务器，直到爱尔兰CouchDB服务器重新启动与他们两个的双向同步，a la:

爱尔兰CouchDB\u复制器伪设置

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

问题1：我对Coach复制失败/恢复的理解是否正确

问题2：如果网络故障在一小时后自行修复（特别是：没有服务器重新启动强制DB在启动时重新初始化），那么相应的CouchDB实例如何对此作出反应？我想美国西部和东京会忘记爱尔兰，但爱尔兰会不会突然再次开始与这两台服务器对话，重新初始化双向、连续复制

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

---

谢谢

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

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

---

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

Robert，这太棒了。在使用SimpleDB、Redis和Mongo之后，我突然意识到Coach对复制的痴迷，这就像我脑子里的一盏灯熄灭了一样。。。突然间，我在NoSQL数据存储/持久性/安全性方面的所有痛点都消失了，我只剩下这个简单、健壮、能够正常工作的系统。非常感谢您的澄清！