rs.slaveOk() 无效是因为它仅影响旧版 mongo shell，新版驱动完全忽略；真正需配置 readPreference（如 secondary）并确保 Secondary 节点状态正常、同步及时、网络可达且配置无误。
从节点读取失败，不是 rs.slaveOk() 没调对，而是根本没配对 readPreference，或者节点压根不满足读取条件。
为什么 rs.slaveOk() 调了也没用
它只影响旧版 mongo shell 的会话行为，新版 mongosh 和所有主流驱动（PyMongo、Node.js Driver、Java Driver）完全忽略该命令。你执行后仍报 "not master and slaveOk=false"，说明问题不在“开关”，而在连接或查询层没指定读取策略。
-
rs.slaveOk()不改变副本集配置，也不影响服务器行为，只是让老 shell “假装允许读” - 应用代码里写
db.getMongo().setSlaveOk()或类似调用，对 PyMongo/Node.js 等毫无意义 - 即使你在
mongosh里执行了它，show dbs依然失败，这是正常现象
怎么让读请求真正落到 Secondary
关键不是调函数，而是把 readPreference 显式塞进连接字符串或操作链里，并确保节点状态和配置匹配。
- 连接字符串示例：
mongodb://host1:27017,host2:27017/?replicaSet=rs0&readPreference=secondary - PyMongo 示例：
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会被拒绝，哪怕连接串写了也无效
Secondary 查不到数据的真正原因
大概率不是权限问题，而是数据没同步过去，或者你连的根本不是活的 Secondary。
- 节点配置了
hidden: true或priority: 0，驱动会自动跳过它，哪怕它确实是SECONDARY - 运行
rs.status()，检查members[n].stateStr是否为SECONDARY，且health为1 - 检查
members[n].optimeDate是否明显落后于主节点（滞后 >30 秒需警惕） - 用
rs.printSlaveReplicationInfo()看同步延迟，0 secs behind才算跟得上 - 确认该节点磁盘 IO（
iostat -x 1）、网络延迟（ping+mtr）是否正常
容易被忽略的配置陷阱
副本集成员看似在线，但可能因配置细节被驱动静默排除。
- 成员 host 字段混用 IP 和 DNS 名——MongoDB 会按字符串精确匹配，
"192.168.1.10:27017"和"node1.example.com:27017"被视为两个不同成员 - keyFile 权限不是
400：MongoDB 5.0 强制要求，600都不行；且chown必须在chmod 400之后做 - SELinux/AppArmor 静默拦截 keyFile 访问，临时测试用
setenforce 0，永久修复需semanage fcontext+restorecon - 反复
rs.remove()+rs.add()后 ID 错乱，必须停全部节点、删local.*文件再重试
