建议使用奇数组。我怀疑的是，从一个奇怪的集合中，我们有一个偶数集。当成员逐一下降时，成员数量在偶数和奇数之间波动。我们总是没有奇怪的成员情景。有人可以解释MongoDB投票的工作原理吗？
答案 0 :(得分：29)
投票由多数投票成员完成。
想象一下有三个（投票）成员的副本集。 假设节点A是主节点，节点B + C是辅助节点。 节点A关闭，因此节点B + C进入选举。他们仍然占多数（三分之二）。选举首先由优先级决定。如果两个节点B＆amp; C具有相同的优先级，然后在失败的主要（oplog）方面最新的那个获胜。让我们说它是节点B.
一旦节点A恢复活着，就没有新的选举。节点B仍然是主节点，C + A现在是辅助节点。
另一方面，如果两个节点关闭，则您没有多数，因此副本集不能再接受更新（应用写入），直到两个失败的服务器中的至少一个变为活动状态（并且已连接）由单个幸存的节点再次。
现在想象一下有四个（投票）成员的副本集。 假设节点A是主节点，节点B + C + D是辅助节点。 节点A关闭，因此节点B + C + D进入选举。他们当然占多数（四分之三）
但是，如果两个节点出现故障，则没有多数（四分之二），因此副本集再次处于只读模式。
这就是推荐奇数的原因;如果您丢失3个成员副本集中的单个成员，则与丢失4个成员副本集中的单个成员相同：您仍然可以获得法定人数多数，并且可以选出新的主要成员（RS仍然可以通过以下方式选择新的主要成员多数）。另一方面，如果你松散了3个成员副本集中的两个成员或4成员副本集（或n成员副本集的n / 2成员） - 再次 - 影响是相同的：没有新的领导者可以投票通过选举。
因此，总而言之，通过在副本集中拥有偶数个成员，不会产生冗余。