Secondary节点读不到最新数据是因异步复制导致的正常过时数据现象，真实同步进度需对比rs.status().members[n].optimeDate与Primary的差值，而非仅看stateStr为SECONDARY。
Secondary节点读不到“脏数据”，但会读到“过时数据”——这是副本集异步复制的必然结果，不是bug，也不是配置错误。
rs.status() 显示 SECONDARY 但数据明显滞后
节点状态为 SECONDARY 只代表它在参与复制，不等于数据已同步完成。真实同步进度要看 optimeDate：连接该节点执行 rs.status().members[n].optimeDate，再和 Primary 的 optimeDate 对比。差值超过几秒就足以让刚写入的订单、库存变更查不到。
- 常见诱因包括磁盘 I/O 瓶颈（
iostat -x 1中await > 50ms就危险）、网络抖动、oplog 被覆盖（日志出现could not find base oplog entry） -
slaveDelay是人为设定的延迟（如备份用），和这种滞后无关；后者是故障信号，前者是功能设计 - 不要只看
stateStr，还要检查health === 1和lastHeartbeatMessage是否持续提示syncing to
aggregate() 在 Secondary 上返回旧快照
MongoDB 的 aggregate() 默认使用 readConcern: "local"，即读取当前节点已应用到的数据——哪怕它比 Primary 落后 30 秒。这不是事务隔离级别问题，而是复制链路固有耗时导致的视图不一致。
- 强一致性场景（如账户余额、库存扣减）必须显式指定
readPreference: "primary"，否则secondaryPreferred会悄悄把请求路由过去 - 若必须从 Secondary 读聚合结果，且能接受“最终一致”，可加
readConcern: { level: "available" }（MongoDB 4.4+），它跳过 majority 提交等待，但依然不解决 lag - 避免在 Secondary 上跑长时
$lookup或大范围$match，这类操作会抢占复制线程所需的 CPU 和磁盘带宽
为什么监控显示 lag=0 却仍读不到最新数据
rs.printSlaveReplicationInfo() 输出的 secsBehindRepl 为 0，只说明 oplog 已拉取完毕，不代表已执行完。真正决定能否查到新数据的是 optimeDate 和本地存储引擎的写入完成时间。
- WiredTiger 引擎中，oplog 条目被解析后需先写入 cache，再刷盘；高负载下 flush 延迟可能达数百毫秒
- 如果应用在写入后立刻用
readPreference: "secondaryPreferred"发起查询，而 Secondary 的optimeDate还没更新，就必然查不到 - 不要依赖
secsBehindRepl判断实时性，它只反映网络传输层进度，不反映存储层执行进度
真正难处理的不是“怎么读得更快”，而是“哪些业务敢读 Secondary”。一旦涉及金额、库存、权限校验，就得默认绕开 Secondary——这不是性能妥协，是数据语义边界问题。
