Secondary节点默认不响应读请求，必须显式设置readPreference=secondary等值；rs.secondaryOk()仅对旧版shell会话生效，新版驱动需在连接字符串或操作中配置readPreference，并确保节点状态为SECONDARY、健康且同步延迟在阈值内。
Secondary节点默认不响应读请求，必须显式设置读偏好
MongoDB副本集的Secondary节点默认拒绝客户端的读操作，这不是权限问题，而是读偏好（read preference）控制机制。调用rs.secondaryOk()只是驱动层的一个便捷方法，本质是向当前连接会话设置readPreference=secondary。它不会修改节点配置，也不需要在Secondary上执行任何命令——这个函数只在客户端（如mongo shell、Node.js驱动、Python PyMongo）中生效。
在mongo shell里正确使用rs.secondaryOk()的步骤
该函数仅对当前shell会话有效，且必须在连接到副本集主节点（或任意成员）后调用：
- 确保连接的是副本集URL，例如：
mongosh "mongodb://rs01:27017,rs02:27017,rs03:27017/?replicaSet=myRepl"，不能只连单个Secondary地址 - 连接成功后直接运行：
rs.secondaryOk()，返回true表示设置成功 - 后续所有集合操作（如
db.users.find()）将自动路由到Secondary节点（满足条件时） - 注意：如果副本集没有可用Secondary（比如全部降级或网络隔离），读操作仍可能回退到Primary，这是驱动的容错行为
Node.js（MongoDB Driver v6+）中等效实现
新版驱动不再支持rs.secondaryOk()，需在连接选项或单次操作中指定readPreference：
- 全局设置（推荐）：
new MongoClient(uri, { readPreference: 'secondary' }) - 单次查询覆盖：
collection.find({}).readPreference('secondary') - 必须确保
uri中包含完整副本集成员和?replicaSet=xxx参数，否则驱动无法识别拓扑结构 - 若遇到
ReadPreferenceServerSelectionError，大概率是副本集状态异常（如rs.status().members[n].stateStr !== "SECONDARY"）或网络不可达
为什么rs.secondaryOk()有时“没反应”？常见盲区
这个函数容易被误认为是服务端开关，其实它既不修改配置文件，也不触发replSetReconfig。失效原因通常与客户端环境强相关：
- 连接字符串未启用副本集发现机制（缺少
replicaSet参数），驱动以单机模式运行，rs.secondaryOk()直接被忽略 - Secondary节点自身状态不是
SECONDARY（比如处于RECOVERING或ARBITER），驱动跳过该节点 - 客户端设置了
maxStalenessSeconds但Secondary延迟超限，自动被排除在候选列表外 - 在分片集群中混用副本集连接方式——
rs.secondaryOk()对mongos无效，读偏好必须通过sh.setSecondaryOk()或驱动配置控制
真正要检查的永远是rs.status()输出里的成员状态和rs.isMaster()返回的hosts/passives字段，而不是反复调用那个shell函数。
