隐藏节点必须同时设置hidden: true和priority: 0，因hidden仅屏蔽客户端发现，priority: 0才禁止参选；缺一者将导致节点仍可见或意外升主。
隐藏节点必须同时设置 hidden: true 和 priority: 0，缺一不可；只设 priority: 0 的节点仍会出现在客户端发现列表中，无法真正“隐藏”。
为什么 hidden 和 priority 必须一起配
隐藏节点的语义是：不参与选举、不被客户端自动发现、不承担常规读流量。但 MongoDB 的设计中，hidden 字段本身**不自动禁用投票权或主节点资格**——它只影响服务发现（如 db.hello() 输出、驱动程序的拓扑扫描）；而 priority 控制的是选举权重。priority: 0 才真正禁止该节点成为主节点，且是 hidden: true 生效的前提条件（官方文档明确要求隐藏节点必须为优先级 0）。
常见错误现象：
- 只设
hidden: true但priority保留默认值 1 → 节点仍可能被选为主，且在rs.status()中可见，驱动仍可能尝试连接 - 只设
priority: 0但未设hidden: true→ 节点不会参选，但仍在副本集拓扑中广播自身，应用连接池可能把它当普通 secondary 路由读请求
配置 hidden 节点的实际操作步骤
必须在主节点上执行，且使用 rs.reconfig()。注意：该操作会触发一次强制选举，主节点会短暂下线。
操作序列示例（假设要隐藏 members 数组中索引为 2 的节点）：
cfg = rs.conf() cfg.members[2].priority = 0 cfg.members[2].hidden = true rs.reconfig(cfg)
关键细节：
- 修改前务必先
rs.conf()拿到当前配置对象，不能直接构造新对象传入rs.reconfig()，否则会丢失其他成员字段（如votes、tags） - 数组索引
[2]是 members 数组位置，不是成员的_id；可用rs.conf().members.map(m => m.host)确认顺序 - 如果副本集启用了
settings.chainingAllowed: true（默认开启），隐藏节点仍可能被其他 secondary 选作同步源，但 MongoDB 会尽量避开它——除非没有其他可用 secondary
备份场景下 hidden 节点的典型使用方式
隐藏节点用于备份时，核心约束是：它只能被显式直连，且不能干扰集群多数写确认（w: "majority"）。
因此需额外配置：
- 确保该节点有投票权（
votes: 1），否则副本集活跃节点数下降，可能导致主节点因失去多数支持而降级；但若你明确不需要它投票（例如仅做离线备份），可设votes: 0，此时务必确认剩余节点数 ≥ 3 且能构成多数 - 备份脚本必须显式连接该节点地址，例如：
mongodump --host rs0/192.168.1.100:27017 --readPreference=secondary不起作用，必须写成mongodump --host 192.168.1.100:27017 - 若节点还配置了
slaveDelay（延迟同步），强烈建议同时设hidden: true和votes: 0，否则延迟节点参与投票会导致多数提交点（majority commit point）严重滞后
容易被忽略的兼容性与权限问题
MongoDB 8.0+ 在分片集群中对直连行为做了严格限制：如果你在分片环境中误将隐藏节点部署在 shard 上，并试图直接连接它执行 mongodump，会收到明确报错："You are connecting to a sharded cluster improperly by connecting directly to a shard. Please connect to the cluster via a router (mongos)."
此外，db.fsyncLock() 这类备份辅助命令，在隐藏节点上执行前需确认：
- 节点运行版本与主节点一致（混合版本 reconfig 可能失败）
- 用户拥有
backup或root角色权限，否则fsyncLock会拒绝执行 -
storage.journal.enabled: true必须开启，否则fsyncLock无法保证文件系统一致性
真正麻烦的不是配置 hidden，而是后续所有依赖它的流程——备份脚本、监控探针、恢复验证——都必须绕过自动发现机制，硬编码目标地址和端口。这点一旦遗漏，整个备份链路就静默失效。
