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

Question

Mongo 文档将此 three-member configuration: primary、secondary、arbiter 列为副本集的最小架构。

那里为什么需要仲裁器？如果主节点发生故障，从节点将看不到心跳，因此它需要成为主节点。换句话说，为什么主要+次要配置不够？这个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 实际上并不知道最后一个成员是否是最后一个成员。它需要其他成员告诉它。

所以是的，这就是你需要第三个人的原因。