为什么仲裁者需要在主 - 次仲裁者MongoDB副本集中进行选举？

Question

Mongo文档列出了这个three-member configuration：主，次，仲裁者，作为副本集的最小体系结构。

为什么在这里需要仲裁者？如果主服务器出现故障，辅助服务器将看不到心跳，因此它需要成为主服务器。换句话说，为什么主/辅配置不够？这个related问题似乎没有解决这个问题，因为它讨论了更多的节点。

Answer 1

假设您只有两台服务器，一台主服务器和一台辅助服务器。

如果突然次要服务器无法到达主服务器，可能是主服务器出现故障（在这种情况下，次服务器应该成为主服务器），但它也可能成为隔离次服务器的网络问题（次服务器一个在契约中）。但是，如果你有一个仲裁器，并且仲裁不能到达主仲裁器，但它可以到达仲裁器，那么这个问题与主仲裁器有关，因此它必须成为新的主仲裁器。如果它不能到达主要的，也不是仲裁者，那么次要人知道问题是他是孤立的/破碎的 - 次要的：（ - 所以他不能成为主要的

Answer 2

如果你把仲裁者下到它核心它本质上是一个非数据保留成员用于投票

仲裁者的一个案例是我在链接的问题中说：Why do we need an 'arbiter' in MongoDB replication?打破CAP的问题，但这不是它的真正目的，因为你可以很容易用数据保存节点替换该仲裁器并具有相同的效果。

但是，仲裁者会有几个好处：

• 占地面积小
• 没有数据
• 无需同步
• 可以立即投票
• 可以从字面上随时随地把你的网络，应用服务器，甚至另一个辅助，以提高你的网络的一部分（这进入分区）。

因此仲裁者是非常有用的，即使在分区的一边（即你的网络没有分区）。

现在来解释基础设置。仲裁器不是必需的，你可以将它分解为一个数据保存节点，但是3个数据保存节点不是最小值（这是保持自动故障转移所需的最小值），2个数据保存节点和1个仲裁器实际上是最小。

现在来回答：

换句话说，为什么不是主+副配置是否足够呢？

因为如果其中一个失败，只剩下50％的选票（2-1 = 1），并且50％不会被归类为MongoDB实际投票的足够多数（由您的rs.config中配置的可投票成员总数）。

同样在这种情况下，MongoDB实际上并不知道最后一个成员是否是最后一个成员。它需要其他成员来告诉它。

所以是的，这就是为什么你需要第三个人。