主节点必须且只能有一个，通过选举产生而非手动指定；可通过priority值影响选举倾向，但所有节点priority总和不得超过1000；从节点数量需匹配容错目标，3节点（3数据）推荐生产使用，超7个投票节点会被拒绝；仲裁节点仅参与投票、不存数据，不可部署多个。
主节点必须且只能有一个，从节点数量取决于容错需求和读负载，不是越多越好。
主节点不能手动指定，但能通过 priority 控制选举倾向
启动时所有节点都处于候选状态，MongoDB 通过选举选出主节点。你无法用命令“设 A 为 Primary”，但可以调整节点权重影响结果：
-
priority值越大（默认 1），越可能被选为主节点；设为 0 表示永不参选（适合冷备或报表节点） - 所有节点的
priority必须是正浮点数，且总和不能超过 1000（否则rs.reconfig()会失败） - 修改后需调用
rs.reconfig()生效，且当前主节点必须在线，否则操作会被拒绝
从节点数量要匹配容错目标，不是堆数量就安全
副本集容错能力 = 节点总数 − 选举所需多数票数。常见配置的实际容错能力如下：
- 3 节点（2 数据 + 1 Arbiter）：最多容忍 1 个节点宕机，但只有 1 份完整数据副本
- 3 节点（3 数据）：容忍 1 节点宕机，有 3 份数据副本，支持本地读取，推荐生产使用
- 5 节点（5 数据）：容忍 2 节点宕机，但同步压力、oplog 增长、网络心跳开销明显上升
- 超过 7 个投票节点会直接被 MongoDB 拒绝 ——
rs.status().votingMembersCount最大为 7
从节点配置不当会导致读不到新数据或写入失败
默认情况下，应用读请求只发给主节点。若想让流量落到从节点，必须显式设置读偏好（read preference），且要注意：
-
secondaryPreferred：优先读从节点，主节点不可用时降级读主节点 -
nearest：按网络延迟选节点，但不保证数据新鲜度 —— 可能读到延迟几秒甚至更久的数据 - 从节点若开启
slaveDelay（如设为 3600 秒），它始终落后主节点一小时，不能用于实时业务读取 - 若从节点
hidden: true，即使它健康，客户端也无法通过任何 read preference 读到它
仲裁节点（Arbiter）只解决投票问题，不解决数据冗余
当只有两个数据节点时，加一个仲裁节点能让投票数变为奇数（3 票），避免脑裂，但它完全不存数据：
- 仲裁节点不能承担读请求，也不能做备份源，
rs.status()中它的stateStr是ARBITER - 不要部署多个仲裁节点 —— MongoDB 允许，但会导致选举逻辑混乱，官方明确警告“
Do not deploy multiple arbiters” - 仲裁节点可跑在低配机器甚至应用服务器上，但必须确保其网络连通性稳定，否则可能意外触发误判和反复选举
真正容易被忽略的是：节点角色不是静态标签，而是运行时动态协商的结果。哪怕你把某台机器配成 priority: 0，只要其他节点全部失联，它仍可能被推举为主节点 —— MongoDB 的设计原则是“宁可短暂双主，也不拒绝写入”，所以容错边界必须靠节点数+网络稳定性共同保障，不能只依赖配置文件里的 priority 或 hidden。
