MongoDB副本集节点宕机时的选举规则与多数派计算疑问

核心结论：多数派的计算依据 #

计算多数派的公式 n/2 + 1 中的 n 指的是副本集的总投票节点数（无论节点当前是否存活），而非当前存活的节点数。这里的「投票节点」是指副本集中配置了投票权的节点（默认情况下，所有数据节点和仲裁节点都拥有1票投票权，可通过 members[n].votes 配置修改）。

你的测试场景差异原因 #

场景1：5节点副本集（4数据+1仲裁） #

此集群总共有5个投票节点，多数派阈值为 5/2 + 1 = 3 票。当关闭3个节点（含仲裁）后，仅剩余2个投票节点，最多只能投出2票，无法达到3票的多数派要求，因此无法完成主节点选举。剩余的2个节点只能维持secondary状态，集群无法提供写服务，默认读操作也会失败。

场景2：3节点无仲裁副本集 #

此集群总共有3个投票节点，多数派阈值为 3/2 + 1 = 2 票。关闭1个节点后，剩余2个投票节点可以互相投出支持票，总票数达到2票，满足多数派要求，因此能成功选举出主节点，集群可正常提供读写服务。

读写关注的影响 #

• 写关注：默认写操作要求主节点确认，若集群无主节点则写操作直接失败；若设置 w: majority 写关注，需要等待多数投票节点确认写入，当存活节点数不足多数时，写操作会持续阻塞直到满足条件，或因超时失败。
• 读关注：默认读操作指向主节点，无主节点时默认读操作失败；若配置 readPreference: secondary 或 secondaryPreferred，在仅有secondary节点的情况下可以读取数据，但读取到的可能不是最新的集群数据。

内容的提问来源于stack exchange，提问作者Noam Guy