rs.conf() 必须在 PRIMARY 节点执行，因其底层读取 local.system.replset（仅主节点维护），secondary 上该集合可能为空或过期；误用 priority、votes、hidden、slaveDelay 易引发选举异常。
rs.conf() 是查看 MongoDB 副本集当前配置信息最直接、最权威的方式，它返回的是副本集的完整配置文档，包括所有成员的 host、priority、votes、hidden、slaveDelay 等关键参数。
注意：这个命令必须在主节点（PRIMARY）上执行，否则会报错 not master 或 not primary and cannot delegate。副节点默认拒绝写操作，而 rs.conf() 本质是读取内部配置集合 local.system.replset，该集合只在主节点可读。
为什么不能在 secondary 上直接运行 rs.conf()？
因为 rs.conf() 底层调用的是 db.getSiblingDB("local").system.replset.findOne()，而 local 数据库不参与复制，其内容仅由主节点维护并用于选举协调。secondary 节点上的 local.system.replset 可能过期或为空 —— 即使你手动连到 secondary 并切换到 admin 数据库，rs.conf() 仍会失败。
- 错误示例：
replSetGetConfig failed: not master - 临时绕过方式（不推荐）：
rs.secondaryOk(true)后再尝试rs.conf()，但结果不可靠，可能返回空或陈旧配置 - 真正安全的做法：先确认连接的是 PRIMARY，用
db.isMaster().ismaster或rs.status().myState === 1
rs.conf() 返回字段里哪些最常被误读？
配置里几个字段看似简单，但含义和影响容易混淆：
-
priority：决定选举权重，不是“谁优先当主”，而是“谁更可能当选”。值为0的成员永远无法成为 PRIMARY（比如隐藏节点） -
votes：是否参与投票。设为0的节点（如延迟节点）不影响多数派计算，但仍是副本集合法成员 -
hidden: true+priority: 0是标配组合；单独设hidden: true而没关priority会导致选举异常 -
slaveDelay单位是**秒**，不是毫秒 —— 设成3600表示延迟 1 小时同步，不是 3600 毫秒
想看配置又不确定连的是不是 PRIMARY 怎么办？
用 db.isMaster() 最快验证：
db.isMaster().ismaster
返回 true 才能放心执行 rs.conf()。如果返回 false，别硬试，先用 rs.status() 查看哪个节点状态是 "stateStr": "PRIMARY"，然后重新连过去。
- 常见陷阱：用连接字符串带多个 host（如
mongodb://n1,n2,n3/?replicaSet=rs0），驱动自动选节点，但 shell 不保证连上的是 PRIMARY - 稳妥做法：先
mongo --host n1:27017显式连某节点，再db.isMaster()确认 - 脚本中建议加判断：
if (db.isMaster().ismaster) { printjson(rs.conf()); } else { print("Not connected to PRIMARY"); }
配置细节一旦写错（比如 votes 和 priority 冲突），可能导致选举卡住或意外降级 —— 这类问题往往不会立刻报错，但会在故障转移时暴露。所以每次修改配置后，务必用 rs.conf() 确认落地结果，而不是只信自己敲的命令。
