rs.slaveok()无效是因为它仅对旧版mongo shell会话生效，新版mongosh及pymongo、node.js等驱动完全忽略该命令；真正控制读取的是readpreference参数，必须在连接字符串或操作中显式设置为secondary等值，并确保节点状态正常、同步完成且未被配置为hidden或延迟同步。
rs.slaveOk() 为什么调了也没用
因为 rs.slaveOk() 只对旧版 mongo shell 会话生效，新版 mongosh 和所有主流驱动（PyMongo、Node.js Driver、Java Driver）完全忽略它。你执行了这句，但查询仍报 "not master and slaveOk=false"，说明问题根本不在“有没有开开关”，而在于读取策略没配对。
真正起作用的是 readPreference 参数，它必须显式出现在连接层或操作层——不是一次设置全局生效，而是每次连接或每次查询都要明确指定。
-
rs.slaveOk()不改变副本集配置，也不影响服务器行为，只骗老 shell “假装允许读” - 如果你用的是
mongosh连接，rs.slaveOk()执行后依然不能show dbs，这是正常现象 - 应用代码里写
db.getMongo().setSlaveOk()或类似调用，对 PyMongo/Node.js 等毫无意义
怎么让应用真正从 Secondary 读数据
关键不是调函数，而是把 readPreference 塞进连接字符串或操作链里，并确保节点状态和配置匹配。
连接字符串示例：mongodb://host1:27017,host2:27017/?replicaSet=rs0&readPreference=secondary
PyMongo 示例（必须 import）：
from pymongo import ReadPreference<br>client = MongoClient('mongodb://...', read_preference=ReadPreference.SECONDARY)
Node.js Driver 示例：
collection.find({}).readPreference('secondary')
-
readPreference=secondary表示“只读 Secondary”，如果当前没有可用 Secondary，查询直接失败 -
readPreference=secondaryPreferred表示“优先读 Secondary，不可用时 fallback 到 Primary” - 事务内强制
readPreference=primary，切secondary会被拒绝，哪怕连接串写了也无效 - 如果节点配置了
hidden: true或priority: 0，驱动会自动跳过它，哪怕它确实是 SECONDARY
Secondary 查不到数据的真正原因往往不是权限
查不到，大概率不是 slaveOk 没开，而是数据压根没同步过去，或者你连的根本不是活的 Secondary。
先确认节点真实状态：rs.status().members[n].stateStr 必须是 SECONDARY，而不是 RECOVERING、ARBITER 或 STARTUP。
再看同步进度：rs.printSlaveReplicationInfo() 输出的 syncedTo 时间戳如果比 Primary 落后几分钟，刚写入的数据自然查不到。
- 节点配置了
slaveDelay: 3600？那它永远比 Primary 少一小时数据 -
local.replset.minvalid集合里_initialSyncFlag是true？说明上次初始同步失败，残留状态卡住同步流程 - 驱动缓存了拓扑，实际节点已宕或网络不通，但 client 还在往旧地址发请求——需要调
client.topology.close()强刷
Secondary 卡在 RECOVERING 怎么办
别试 db.runCommand({ resync: 1 })，这个命令在副本集架构中自 MongoDB 3.2 起就彻底删除了，任何版本（包括 6.x / 7.x）执行都只会返回 "no such cmd: resync"。
唯一可靠做法：清空 dbPath 目录后重启。这不是暴力，是标准流程。
- 先停 mongod：
db.shutdownServer()或系统级 kill - 备份
diagnostic.data（可选但推荐），然后 整个dbPath目录删干净（不是只删 data 子目录） - 启动时确保配置中
replSetName、端口、bindIp完全匹配原集群 - 观察日志出现
"Starting initial sync"才算真正触发重同步 - 源节点 oplog 必须够长——用
rs.printSecondaryReplicationInfo()看最长延迟，否则新节点又会因 oplog 断档卡回 RECOVERING
最常被忽略的一点：Secondary 能不能读，不取决于你写了多少行配置，而取决于它有没有完成同步、有没有被驱动识别为可用节点、以及你的读请求是否真的路由到了它身上。中间任一环节断掉，readPreference 就只是个摆设。
