为何MongoDB副本集在Secondary节点宕机后写入功能异常？

核心原因：副本集主节点的主状态维持机制 #

MongoDB副本集的主节点（PRIMARY）要保持主状态，必须能与大多数投票成员保持连通。这里的“大多数”指超过投票成员总数的半数：

• 初始配置里，你有4个投票成员（3个数据节点+1个仲裁者），总数为4，因此大多数为3（即需要至少3个投票成员在线且可连通）。
• 当你关闭那个优先级为0的SECONDARY节点（它属于投票成员）后，可用投票成员仅剩3个：主节点、优先级1的SECONDARY、仲裁者。此时如果主节点与其中任意一个投票成员的心跳出现短暂超时（比如网络波动），可用投票成员数会降至2，无法满足“大多数（3）”的要求，主节点会立即降级为SECONDARY。此时副本集没有主节点，客户端的写入请求找不到目标，就会出现阻塞。

为什么设置投票权为0后问题消失？ #

当你把该节点的投票权设为0后，它不再属于副本集的投票成员，此时总投票成员数变为3（主节点、优先级1的SECONDARY、仲裁者），对应的大多数为2。关闭该非投票节点后，3个投票成员全部在线，主节点只要能与至少1个其他投票成员保持连通，就能维持主状态，因此不会出现降级和写入阻塞的情况。

关于写入路由的误区 #

你同事的说法是错误的：MongoDB副本集的写请求只会路由到主节点，客户端驱动会自动识别主节点并发送写入请求，不会随机写入从节点。你的问题本质不是写入路由错误，而是主节点的状态稳定性问题。

优化建议 #

• 如果该优先级为0的节点仅用于数据备份、只读查询，不需要参与选举，建议将其投票权设为0，从投票成员中移除，减少主节点维持状态的压力。
• 副本集投票成员的数量建议设置为奇数（比如3、5），这样可以避免出现“半数分裂”的情况，提升集群的可用性。

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