奇数节点能避免选举平局，因副本集依赖多数派投票机制，新主节点需获超半数投票；偶数节点易出现票数相等导致选举失败，如4节点时2:2无法满足>2票要求；仲裁节点仅投票不存数据，须物理隔离部署且不可与数据节点共机。
奇数节点能避免选举平局
副本集选举依赖多数派（majority）投票机制，即新主节点必须获得超过半数投票节点的支持才能当选。偶数节点时，容易出现 3:3、2:2 这类票数相等的情况，导致无法选出主节点，整个集群卡在 SECONDARY 状态，写操作不可用。
例如：4 节点副本集，若网络分区将节点拆成 2+2 两组，每组都只有 2 票，达不到「超过半数」（即 >2）的要求，两边都无法触发选举，服务中断。
- 3 节点 → 多数派是 2 票，任意 2 节点在线即可完成选举
- 5 节点 → 多数派是 3 票，最多容忍 2 节点宕机或失联
- 4 节点 → 多数派是 3 票，但只要 2 节点失联，剩余 2 节点无法凑够 3 票，选举失败
仲裁节点（arbiter）不是万能解药
arbiter 不存数据、不服务读请求，只参与投票，资源开销小，常被用来把偶数数据节点“补成奇数”。但它本身不提供冗余能力——如果 arbiter 所在机器宕机，又恰好剩下偶数个数据节点，依然可能陷入平局。
更关键的是：arbiter 必须和数据节点物理隔离。MongoDB 明确禁止将 arbiter 和 primary 或 secondary 部署在同一台机器上，否则失去容错意义。
- 不要把
arbiter和任何mongod实例共用同一台服务器 - 不要为节省资源，把
arbiter塞进应用服务器再加个--bind_ip=127.0.0.1就完事——它必须能被所有数据节点通过 DNS 主机名访问到 - 从 MongoDB 5.0 起，仅配置 IP 地址的
arbiter节点会启动失败，必须用主机名
节点数不是越多越好，7 是投票上限
副本集最多支持 50 个成员，但只有前 7 个配置了 votes: 1 的节点能参与主节点选举。超出的节点即使设为 voting: true，也会被忽略；必须显式设为 votes: 0，否则 rs.reconfig() 会报错 cannot add more than 7 voting members。
这意味着：加第 8 个数据节点，如果不调整配置，它根本投不了票，也无法被选为主节点，纯属冗余存储，还拖慢 oplog 同步速度。
- 新增节点默认
votes: 1，部署前务必检查rs.conf().members - 延迟节点（
slaveDelay）、隐藏节点（hidden: true）、优先级为 0 的节点（priority: 0），通常应同步设votes: 0 - 滚动升级期间允许短暂版本混搭，但长期运行必须统一主版本号，否则某些选举逻辑可能异常
真实部署中，奇数 ≠ 安全，关键是网络拓扑
3 个节点全在同一个机房、同一交换机、同一供电线路下，哪怕数量是奇数，一次机柜断电就全挂——这时奇数只是数学正确，工程上无效。
MongoDB 官方要求：生产环境每个 mongod 实例应部署在独立物理主机（或强隔离虚拟机）上，且具备冗余电源与网络路径。DNS 主机名必须稳定解析，不能依赖 /etc/hosts 临时映射，否则节点重装或 IP 变更后 rs.status() 会持续显示 STARTUP2 或 REMOVED。
最容易被忽略的一点：--bind_ip 如果漏配或配错，节点可能监听在 127.0.0.1，导致其他成员连不上，看似“3 节点在线”，实则只有本地回环通信，选举永远无法达成共识。
