rs.slaveok() 不起作用是因为它仅影响旧版 mongo shell 的当前会话，新版驱动（如 mongosh、pymongo、node.js）完全忽略该命令；真正控制读取的是 readpreference 参数，需在连接字符串或操作中显式设置为 secondary 等值，并确保节点状态正常、同步完成且未被配置为 hidden 或延迟同步。
为什么 rs.slaveOk() 不起作用了
MongoDB 4.0+ 默认禁用从 Secondary 节点读取，rs.slaveOk() 只是客户端驱动层面的旧式开关，它不改变服务器策略，也不影响连接字符串或会话级读取偏好。你调了这句，但查询依然报 not master 或直接路由到 Primary，说明问题不在“有没有开”，而在“怎么读”。
-
rs.slaveOk()仅对当前 shell 会话生效，且只影响 legacy driver（如老版 mongo shell），新版 mongosh 和大多数应用驱动（Node.js、Python PyMongo）完全忽略它 - 真正控制读取行为的是
readPreference参数，必须显式设置在连接层或操作层 - Secondary 节点本身可能未启用读取（
secondaryReadsEnabled: false），或被配置为hidden: true/priority: 0，导致驱动自动跳过
如何让应用真正从 Secondary 读数据
关键不是调函数，而是配对读取策略和连接方式。不同场景下写法差异大，错一个参数就读不到。
- 连接字符串里加
readPreference=secondary：比如mongodb://host1,host2/?replicaSet=rs0&readPreference=secondary - Node.js（MongoDB Driver）中显式指定：
collection.find({}).readPreference('secondary')，注意这是方法链调用，不是全局设置 - PyMongo 中用
read_preference=ReadPreference.SECONDARY初始化 client 或传给 find()，别漏了from pymongo import ReadPreference - 如果用了事务，Secondary 读直接被拒绝——事务强制要求
readPreference=primary，此时切 Secondary 就是无效操作
Secondary 查不到数据的常见隐藏原因
不是权限没开，而是数据根本没同步过去，或者你连的根本不是 Secondary。
- 检查节点状态：
rs.status().members[n].stateStr必须是SECONDARY，而不是RECOVERING或ARBITER - 确认同步延迟：
rs.printSlaveReplicationInfo()看syncedTo时间戳，如果落后几分钟，刚写入的数据自然查不到 - 副本集配置里该节点设了
slaveDelay: 3600（延迟一小时同步），那它永远比 Primary 少一小时数据 - 驱动自动剔除了不可用节点：比如 Secondary 的
health: 0或网络不通，驱动缓存了拓扑，需要重启连接或调用client.topology.close()强刷
readPreference 各值的实际行为差异
选错值会导致“以为在读 Secondary，其实还在读 Primary”，尤其在负载不均时难察觉。
-
primary：强制走 Primary，事务唯一合法值 -
primaryPreferred：优先 Primary，Primary 挂了才切 Secondary —— 这是默认值，很多人误以为它能读 Secondary -
secondary：严格只读 Secondary，Primary 不参与，但所有 Secondary 都不可用时会报错 -
nearest：按网络延迟选最近节点（可能是 Primary 或 Secondary），适合跨机房低延迟读，但不保证数据新鲜度
最常踩的坑是：开发环境用 primaryPreferred 测试正常，上线后流量全打到 Primary 上，根本没触发 Secondary 分流。
