db.isMaster()中判断Primary的关键字段是ismaster和primary：ismaster为true表示当前连接节点是Primary，primary字段则指向副本集公认的Primary地址。
直接执行 db.isMaster() 就能知道当前连接的节点是不是 Primary，但要注意它返回的是“你连上的这个节点”的状态，不是整个副本集里谁是主 —— 这点容易误判。
db.isMaster() 返回值中哪个字段代表 Primary
关键看两个字段：ismaster 和 primary：
-
ismaster: true表示你当前连接的节点就是 Primary（仅限该节点） -
primary: "host:port"是整个副本集当前公认的 Primary 地址（无论你连的是谁，这个字段都指向真正的主） - 如果连的是 Secondary，
ismaster为false，但primary字段依然存在且有效
示例（连上某个 Secondary 节点后执行）：
db.isMaster()
{
"ismaster": false,
"secondary": true,
"primary": "192.168.56.254:27017",
"hosts": [ "192.168.56.254:27017", "192.168.56.66:27018" ],
...
}
为什么不能只信 ismaster 字段
常见误操作：在某个 Secondary 上执行 db.isMaster()，看到 ismaster: false 就以为“没主了”，其实只是你连错了节点。
- 副本集可能正常运行，Primary 也在线，但你连的是一个配置了
hidden: true或priority: 0的只读节点 - 网络分区时，部分节点可能认为自己还是 Primary（出现“双主”假象），但
primary字段会因选举未完成而缺失或过期 -
ismaster是瞬时状态，受心跳超时（默认10秒）、选举过程影响；primary字段更接近集群共识结果
更可靠的判断方式：配合 rs.status()
rs.status() 比 db.isMaster() 多一层验证，尤其适合排查异常：
- 检查
members[n].stateStr—— 值为"PRIMARY"的那个成员才是当前主节点 - 确认
members[n].health === 1，避免看到已掉线但状态未刷新的“幽灵 Primary” - 对比
members[n].optimeDate，Secondary 落后太多（比如 >30 秒）可能被标记为STALE，即使stateStr显示"SECONDARY"也不可靠
注意：rs.status() 必须在已初始化副本集的节点上执行，否则报错 "no replset config has been received"。
Shell 中快速定位 Primary 的一行命令
不想翻 JSON？用这个过滤命令直接提取地址：
db.isMaster().primary
或者更稳妥一点（兼容无 primary 字段的情况）：
rs.status().members.filter(m => m.stateStr === "PRIMARY")[0]?.name
但注意：这个表达式依赖 JavaScript 运行环境，旧版 mongosh（如 v1.0 以下）不支持可选链 ?. ，得写成传统 if 判断。
真正容易被忽略的点是：副本集里可能根本没有活跃的 Primary —— 比如只剩两个节点且网络不通，或仲裁节点挂了导致无法达到多数派。这时 primary 字段为空，rs.status() 里所有成员的 stateStr 都不是 "PRIMARY"，但 myState 可能还是 1（伪主）。这种状态不会自动恢复，必须人工介入检查投票权和网络连通性。
