secondaryPreferred在聚合中仍走主节点，根本原因是$lookup、$out、$merge等阶段隐式触发写或事务行为，驱动自动降级为primary读偏好，即使显式设置也无效。
为什么 secondaryPreferred 在聚合操作中仍走主节点
根本原因不是副本集没生效，而是 MongoDB 的聚合管道（$lookup、$out、$merge 等阶段）会隐式触发写或事务行为，驱动自动降级为 primary 读偏好——哪怕你显式设了 secondaryPreferred。
常见表现：用 db.collection.aggregate([...]) 发起聚合，监控看到从节点完全空闲，所有 getMore 和后续 cursor 请求都落在主节点上。
-
$lookup阶段如果目标集合在另一个分片或需跨节点解析引用，驱动会强制切回primary以保证一致性 -
$out或$merge是写操作，必须路由到主节点；即使聚合前半段尝试走从节点，一旦管道含这类阶段，整个命令就在主节点执行 - 带
allowDiskUse: true的聚合，在某些驱动版本中也会绕过 readPreference，因临时文件协调逻辑依赖主节点元数据
secondaryPreferred 对聚合生效的前提条件
它只对“纯读”聚合有效，即不含任何写语义、不跨集群、不触发因果一致性检查的管道。一旦不满足，MongoDB 客户端驱动会在执行前静默覆盖你的设置。
- 必须排除
$out、$merge、$facet（部分旧版驱动对$facet也强制主节点） -
$lookup目标集合必须与源集合在同一副本集内，且目标集合的readPreference未被单独覆盖 - 连接字符串或客户端配置中的
maxStalenessSeconds必须合理（如30），否则驱动发现所有 secondary 都超延迟，直接 fallback 到 primary - Node.js 驱动中，若在
aggregate()调用后链式调用.readPreference('secondaryPreferred')，必须确保没被上层封装函数重置（比如 ORM 层默认插件会强制 primary）
怎么验证聚合到底走了哪个节点
别信连接字符串或代码里的设置，直接查 profile 日志最准：
- 先在目标数据库开启 profiling：
db.setProfilingLevel(2) - 执行一次聚合，然后查
db.system.profile.find({ 'command.aggregate': { $exists: true } }).sort({ ts: -1 }).limit(1) - 重点看返回结果里的
originatingCommand.readPreference字段值，以及originatingCommand.$readPreference（旧版驱动用这个） - 再配合
db.runCommand({ replSetGetStatus: 1 })确认 secondary 的optimeDate和状态是否正常（stateStr: "SECONDARY"且延迟）
真正可控的聚合读写分离方案
靠单一 readPreference 参数无法兜住聚合场景，得组合策略：
- 把聚合拆成两步：先用
find()+secondaryPreferred拿原始数据，在应用层做关联或轻量计算；重聚合逻辑下沉到定时 job，走主节点离线处理 - 对必须在线聚合的场景，改用
nearest+localThresholdMS=15，比secondaryPreferred更容错——它不挑主从，只选延迟最低的活跃节点 - Java/Python 驱动中，显式传
ReadPreference.secondaryPreferred()到aggregate()方法参数里（而非只设 client 默认值），优先级更高，不易被覆盖 - 如果用了 MongoDB 6.0+，可尝试
readConcern: "available"配合secondaryPreferred，它允许读取尚未提交到 majority 的数据，降低对同步延迟的敏感度
最常被忽略的一点：聚合是否走 secondary，不取决于你写了什么偏好，而取决于驱动在解析完整个 pipeline 后，是否判定“当前操作能安全地离开主节点”。这个判定发生在请求发出前，且不可见、不可 debug —— 所以验证必须靠 profile 日志，而不是日志打印或监控图表。
