Secondary节点默认不参与读操作，根本原因是驱动未配置有效的readPreference参数；必须在连接字符串或操作中显式设置secondary等值，并确保节点状态为SECONDARY、health=1、同步延迟在maxStalenessSeconds范围内。
Secondary节点默认不参与读操作，不是“不能”，而是“没被客户端选中”——根本原因在驱动配置的 readPreference 没生效。
为什么连上Secondary却查不到数据？
直连某个 SECONDARY 节点（比如用 mongosh --host node2:27017）执行 db.collection.find() 报错或返回空，常见于以下情况：
- 你没在连接字符串里显式指定
readPreference=secondary，驱动仍按默认primary行为发请求，但该节点拒绝读（实际不会报错，但可能因心跳未同步而返回陈旧/空结果） - 节点状态不是
SECONDARY，而是STARTUP2、RECOVERING或ARBITER，这些状态不接受读请求 - 副本集未完成初始同步（
initial sync），optime远落后于PRIMARY，驱动根据maxStalenessSeconds自动跳过该节点
Node.js 驱动中 readPreference 的真实行为
readPreference 不是“开关”，而是一组带优先级和约束的路由策略。它只在使用高可用连接串（含全部节点地址）时才起作用；单点直连时该参数被忽略。
-
readPreference=primary：所有读写都发给当前PRIMARY（默认值） -
readPreference=secondary：只发给健康SECONDARY节点，若无则报错No replica set members available -
readPreference=secondaryPreferred：优先发SECONDARY，失败后自动 fallback 到PRIMARY - 搭配
readPreferenceTags可绑定标签（如region:us-east），但所有匹配节点必须同时满足readPreference类型和标签条件
示例连接串：mongodb://node1:27017,node2:27017,node3:27017/?replicaSet=rs0&readPreference=secondary&maxStalenessSeconds=60
检查 rs.status() 输出里的关键字段
连上任意节点执行 rs.status() 后，重点看每个成员的这几个字段：
-
stateStr：必须是SECONDARY（不是ARBITER或RECOVERING） -
health：必须为1（0 表示失联） -
optime.dts与PRIMARY的差值：若超过maxStalenessSeconds设定值，该节点会被自动剔除出读候选池 -
tags：若用了readPreferenceTags，这里必须包含对应键值对，否则不匹配
容易被忽略的兼容性陷阱
不同版本驱动对 readPreference 的解析逻辑有差异，尤其在云厂商封装的连接串中：
- 老版本 Node.js 驱动（readPreferenceTags 数组语法，只认字符串形式
- 某些云数据库控制台生成的连接串会强制覆盖你的
readPreference，需手动在 URI 后追加参数 -
maxStalenessSeconds最小值为 90 秒（MongoDB 3.6+），设成 30 会被静默提升，导致你以为“就近读”实则全走主节点 - 使用
mongoose时，readPreference必须写在connect()的options里，写在 Schema 或 Model 层无效
最稳妥的做法：始终用 rs.status().members 确认节点真实角色与延迟，再比对驱动实际发出的请求目标——别只信连接串里写了什么。
