为什么三个节点是 Couchbase 推荐的最小节点数？

Question

对于 Cassandra，假设复制因子为 1（即数据集的两个副本），至少需要三个节点才能启用具有强一致性的写入。 Couchbase 的情况似乎并非如此，至少我没有发现它在任何地方说明。尽管如此，Couchbase 仍然建议生产系统至少使用三个节点。

我发现的唯一动机是（1）双节点系统中的单节点故障会产生单点故障，以及（2）双节点系统在扩展到第三个节点时需要更加努力，而不是三节点系统（我假设这是因为重新平衡）。

没有一个动机对我来说特别有吸引力：

原因（1）感觉有点像说两盘的RAID-1没用，只有三盘的RAID-6（一个数据，两个校验）可以接受。尽管如此，RAID-1 还是相当流行的（比三磁盘 RAID-6:es 更受欢迎），并且通常被认为是相对安全的。据推测，一个节点的丢失会导致管理员快速采取行动，因此风险应该是短暂的。

原因 (2) 对我来说似乎更短暂。添加第三个节点比添加第四个节点时三个节点需要更努力地工作。不过，这只是一个问题，而且大多数应用程序的负载每天都有变化，可以进行重新平衡的适配。

所以我想知道是否还有其他原因可以避免使用两个节点的 Couchbase 集群，假设两个节点能够很好地承载负载？

Answer 1

主要原因是在少于三个节点的情况下禁用了自动故障转移。这是为了防止出现“脑裂”的情况。考虑两个节点，节点 A 和节点 B。如果一个节点不可达（由于网络问题），则：

• 节点 A 无法访问节点 B，并且没有其他节点可以协商，因此他进行故障转移（从集群中删除 B 并提升自己的副本）
• 节点 B 无法到达节点 A，同样没有其他节点，因此他进行故障转移（从集群中删除 A）。

任何仍然可以看到两个节点的客户端现在基本上都有两个独立的集群，它们都认为自己拥有整个数据集。

在这种情况下，您基本上违反了 CAP 中的一致性。

因此，Couchbase不会在少于三个节点的情况下执行自动故障转移，并且由于这是在生产系统中使用的推荐功能，因此您的集群中至少需要三个节点。

有关详细信息，请参阅 Couchbase 管理员指南中的 Failover considerations 章节。