MongoDB副本集投票节点上限为7个且必须为奇数，3或5个最常用；非投票节点需同时设votes:0和priority:0；仲裁节点不存数据，仅参与选举，不提升数据可靠性。
副本集投票节点不能超过 7 个
这是硬性限制，不是建议。MongoDB 副本集最多只允许 7 个投票节点（votes: 1），超出的节点必须设为 votes: 0。即使你部署了 50 个节点，也只有前 7 个（按配置顺序）能参与选举——其余节点若未显式禁用投票权，rs.reconfig() 会直接失败并报错：MongoServerError: too many voting members。
投票数必须是奇数，且多数票 = floor(N/2) + 1
偶数投票节点会导致选举僵局。比如 4 个投票节点，需要 3 票才能构成 majority，但一旦任意 2 个节点宕机，剩下 2 个无法达成多数，主节点无法选出，整个副本集写入不可用。
- 3 节点 → majority =
2，容错 1 个节点 - 5 节点 → majority =
3，容错 2 个节点 - 6 节点 → majority =
4，容错仍只有 2 个节点（和 5 节点一样），但多出一个投票节点纯属冗余，还增加选举开销
所以实际部署中，**3 或 5 个投票节点是最常见、最经济的选择**；7 仅在极少数高可用要求场景下使用。
非投票节点必须 priority = 0
想加更多节点分担读负载或做备份？可以，但它们必须同时满足两个条件：
votes: 0priority: 0
漏掉任一条件，rs.reconfig() 会拒绝生效。常见错误是只改 votes 忘了 priority，结果节点依然试图参选，但因无票被踢出选举流程，日志里反复出现 not electable 提示。
仲裁节点不是“免费保险”，它有明确副作用
用仲裁节点凑奇数投票数（比如 P-S-A 架构）确实省资源，但它不存数据，也不参与数据同步。这意味着：
- 写关注
w: "majority"实际只等 2 个节点（主 + 从），仲裁节点不参与确认 —— 但它计入 majority 计算，所以 3 节点时 majority 仍是2，没问题； - 但如果从节点延迟或宕机，写操作会卡住，因为 majority 无法达成；
- 多个仲裁节点在 MongoDB 5.3+ 默认被禁止，强行启用需启动参数
--setParameter 'allowMultipleArbiters=true'，但官方明确警告：这会破坏数据一致性保障。
真正容易被忽略的是：仲裁节点让副本集「看起来」有容错能力，但实际数据副本只有 1 份（主节点），它的存在只为保选举不断，不保数据不丢。
