Hidden节点不能同时设priority: 0和votes: 1，因MongoDB启动或reconfig时会报“cannot vote and be hidden”错误；必须三者联动：hidden: true、priority: 0、votes: 0。
Hidden节点为什么不能同时设置 priority: 0 和 votes: 1
因为 MongoDB 会直接拒绝这种配置：启动或 reconfig 时抛出 "cannot vote and be hidden" 错误。Hidden 节点必须明确放弃投票权，否则违背“隐藏即不可见、不可参与决策”的设计语义。实际中常见错误是照搬普通从节点配置，只加 hidden: true 却漏掉 votes: 0 和 priority: 0，导致副本集无法完成选举或 config 更新失败。
正确做法是三者联动：
-
hidden: true—— 对客户端不可见（不响应读请求，不显示在rs.status()的主列表里） -
priority: 0—— 禁止被选为 Primary（即使健康也不参与竞选） -
votes: 0—— 不参与任何选举投票（包括新 Primary 选举和 config 版本确认）
如何安全添加 Hidden 节点到现有副本集
不能直接用 rs.add() 加带 hidden 的节点——它会立刻尝试参与当前选举，可能引发短暂脑裂或投票异常。必须走两步：先以普通从节点加入，再通过 rs.reconfig() 原地升级为 Hidden。
实操步骤：
- 在目标机器启动 mongod，确保
replSet名称与现有集群一致，且能连通其他成员 - 在 Primary 上执行
rs.add("host:port")，等待该节点状态变为SECONDARY（rs.status().members查看） - 获取当前配置：
cfg = rs.conf()，找到新节点的_id，修改其配置段：
cfg.members[2].hidden = true; cfg.members[2].priority = 0; cfg.members[2].votes = 0;
然后执行 rs.reconfig(cfg, {force: true})（仅当 Primary 不可用时才需 force；正常情况无需）
限制 Hidden 节点资源占用的关键配置项
Hidden 节点虽不服务读请求，但仍同步 oplog、构建索引、执行后台任务，CPU 和内存可能悄悄拉高。光靠 hidden 标志无法限流，必须配合以下参数：
- 启动时加
--setParameter enableLocalhostAuthBypass=false（防止意外绕过认证） - 在
mongod.conf中设置replication.rateLimitMBPerSec: 2（限制 oplog 同步带宽，默认无上限） - 使用
processManagement.cpuAffinity: 0x00000003（Linux 下绑定到特定 CPU 核，避免抢占主节点资源） - 若启用 WiredTiger 缓存，务必调低
storage.wiredTiger.engineConfig.cacheSizeGB，Hidden 节点通常设为主节点的 1/3～1/2
注意：rateLimitMBPerSec 是全局配置，会影响所有从节点，如只需限制某一个，得靠系统级 cgroups 或容器 CPU quota。
Hidden 节点的读写行为与监控盲区
Hidden 节点默认不接受任何客户端读请求（即使显式指定 readPreference=secondary），但仍有两个例外场景容易被忽略：
- 使用
mongodump --host直连该节点时，仍可成功备份（它仍是合法的 mongod 实例） - 如果应用层硬编码连接字符串指向 Hidden 节点 IP，驱动可能因 DNS 缓存或错误发现机制而发请求过去（虽不会返回数据，但会增加连接开销）
监控时，rs.status().members 中 Hidden 节点的 stateStr 显示为 HIDDEN，但 lastHeartbeatRecv 和 optimeDate 仍持续更新。真正要盯的是 pingMs 是否突增（网络问题）、lastAppliedWallTime 是否滞后（同步卡住），这些指标在 Hidden 节点上一样有效，别因“隐藏”就忽略它的健康信号。
