rs.conf()返回的priority值与设置不一致是因为配置未通过rs.reconfig()提交并获多数节点确认；权重生效还需满足健康、数据最新、有投票权且未隐藏等条件。
rs.conf() 返回的 priority 值和你设的不一致
这通常不是缓存问题，而是配置未真正提交到副本集。MongoDB 的成员权重（priority）必须通过 rs.reconfig() 显式更新，且新配置需被多数节点确认才能生效。直接改 mongod.conf 或 rs.initiate() 中的初始配置，对已运行的副本集无效。
常见错误包括：
- 用
rs.initiate()初始化后，又手动修改了rs.conf()对象但没调用rs.reconfig() - 调用
rs.reconfig()时漏掉{ force: true }（当主节点不可达或版本不匹配时必需） - 配置中混用了
_id和host不匹配的成员——比如删掉一个节点后没清理旧_id，导致 reconfig 失败静默回退
验证方式：执行 rs.conf() 后，检查返回对象里对应成员的 priority 字段是否为你期望的值；再执行 rs.status().members，确认 stateStr 是 PRIMARY 或 SECONDARY，且 priority 已同步。
成员始终无法当选主节点，即使 priority=2
权重只是选举条件之一，不是“设了就上”。MongoDB 要求候选节点同时满足：
- 健康状态：
health: 1（rs.status().members[n].health） - 数据最新：
optimeDate不能比多数派落后太多（默认容忍 10 秒，可通过electionTimeoutMillis调整） - 有投票权：
votes: 1（仲裁节点votes: 0，不参与投票） - 未被隐藏：
hidden: false（隐藏节点即使priority > 0也不会参选）
最容易被忽略的是 hidden 和 priority 共存——比如你设了 priority: 2 但忘了关 hidden: true，那这个节点永远进不了选举池。检查命令：rs.conf().members[n]，确认这两项没冲突。
配置文件里写了 priority，但 rs.conf() 里看不到
mongod.conf（或 YAML 配置）里的 replication 段只控制启动参数，**不定义副本集成员属性**。成员的 priority、hidden、tags 等全部由副本集配置文档（即 rs.conf() 返回的对象）管理，和本地配置文件无关。
所以你在 mongod.conf 里加：
replication: replSetName: "rs0" # ❌ 这里写 priority 是无效的 # priority: 2 ← MongoDB 忽略这一行
正确做法是：先启动所有节点（确保能通信），再连到主节点执行 rs.reconfig() 更新成员字段。如果用 mongocli 部署，权重必须写在集群配置文件的 processes[n].priority 字段里，而不是 mongod.conf。
rs.reconfig() 报错 “Configuration is older than current”，怎么强制更新
这是副本集拒绝旧版本配置的保护机制。当你从备份恢复配置、或多个管理员并发修改时容易触发。核心原因是 rs.conf()._id（即配置版本号 version）小于当前集群记录的版本。
安全绕过方式只有两个：
- 用
rs.reconfig(conf, { force: true })—— 仅限你确定自己掌握最新配置，且集群处于可维护窗口期 - 先执行
rs.conf()拿到当前配置，把它的version字段 +1，再带这个新版配置调用rs.reconfig()
注意：force: true 不会跳过健康检查，如果目标节点失联或数据严重滞后，仍会失败。此时必须先修复节点状态，再重试。
权重设置本身很简单，难的是它依赖整个副本集的状态链：网络通、心跳稳、oplog 同步快、配置版本对、角色标记清。任何一环断掉，priority 就只是个静态字段，不会触发选举逻辑。
