MongoDB副本集不支持“仅备用”节点，新增节点默认参与选举和读请求；需显式设priority:0、votes:0、hidden:true才能实现真正备用，否则会破坏多数决逻辑。
不能直接把第四个节点加成“备用”角色——MongoDB 副本集不支持标记某个节点为“仅备用”或“冷备”。新增节点默认参与选举、同步数据、接受读请求，除非你显式限制它的行为。
rs.add() 后节点立即开始同步和投票
执行 rs.add() 添加第四个节点后，它会立刻加入 oplog 同步流，同时获得 1 票投票权。这意味着：副本集总票数变成 4，但选举要求多数票（即 ≥3 票）才能选出主节点；如果其中两个节点同时宕机，剩余两个节点无法达成多数，集群将不可写。
- 必须确保
members[n].votes和members[n].priority显式设置，否则新节点默认votes: 1、priority: 1 - 若只想让它做数据热备（不参与选举、不被选为主），需设
votes: 0且priority: 0 -
hidden: true或delayed: true可进一步控制读流量或时间延迟，但不影响投票资格
设置 priority: 0 和 votes: 0 才算真正“备用”
所谓“备用”，实际是指该节点永不参选、不抢主、不投票，只被动同步数据。这需要在添加时或添加后通过 rs.reconfig() 修改其配置：
cfg = rs.conf()
cfg.members[3].priority = 0
cfg.members[3].votes = 0
cfg.members[3].hidden = true // 可选：避免应用路由到它
rs.reconfig(cfg, {force: true})
-
priority: 0：禁止该节点在选举中被提名为主节点 -
votes: 0：移除其投票权，保障三节点多数决逻辑不变（仍为 3/3 或 2/3） -
hidden: true：让该节点不出现在isMaster响应中，驱动不会向它发读请求 - 必须带
{force: true}（尤其当主节点不可达时），否则rs.reconfig()可能拒绝执行
注意 hidden 节点无法执行写操作，也不接受客户端连接
hidden: true 的节点虽然同步数据，但对客户端完全不可见——mongosh 连不上它，应用驱动也发现不了它。这意味着：
- 你无法用
mongosh直连这个节点查数据或导出备份 - 它不能用于手动故障转移测试（比如
rs.stepDown()后看谁接任） - 如需临时启用它为可读节点，得先
rs.reconfig()改回hidden: false，再等几秒让它出现在isMaster中 - 日志里会出现
Member is hidden and will not receive reads类提示，属正常现象
真正可用的“备用”不是靠加节点数量堆出来的，而是靠精确控制 priority、votes、hidden 这三个字段组合实现的；漏掉任意一个，都可能破坏选举逻辑或暴露非预期读路径。
