MongoDB 7.0副本集扩容期间聚合管道会主动熔断而非中断，是在主节点切换、从节点oplog追赶延迟＞10秒等场景下自动拒绝复杂聚合或回退旧引擎，以保障结果准确性和稳定性。
副本集扩容期间，聚合管道默认会中断或降级执行——这不是 bug，而是 MongoDB 7.0 的主动保护机制。 它会在主节点切换、新从节点同步未完成、oplog 追赶延迟 > 10 秒等场景下，自动拒绝含 $lookup、$group、$sort 等阶段的聚合请求，或回退到旧引擎并记录 Query execution using legacy engine。关键不在“能不能跑”，而在“跑得准不准、稳不稳”。
扩容时聚合失败的典型错误信号
你不是配置错了，而是集群状态触发了安全熔断：
-
ReadConcernMajorityNotAvailableYet：常见于新加入的从节点 oplog 落后太多，mongos 拒绝发起跨分片（哪怕当前是副本集）的强一致性聚合 -
not master and slaveOk=false：应用直连了某个正在同步中的从节点，且未设readPreference=secondaryPreferred - 聚合返回结果明显缺失、时间错乱（如某段轨迹数据“跳帧”），其实是部分 shard 返回了旧快照，而其他 shard 返回了新写入
- 日志里反复出现
interrupted at shutdown或moveChunk failed: NotMaster——说明 balancer 正在迁移 chunk，但主节点发生切换，聚合被中止
必须绕开的三个访问陷阱
很多团队以为只要加个节点就完事，却在客户端埋下聚合断裂点：
- 应用连接字符串仍含老节点地址（如
mongodb://old-node:27017,old-node2:27017/?replicaSet=rs0），没更新为包含新节点的完整列表，导致 mongos 无法感知新成员上线 - 没显式指定
readConcern: "majority"和writeConcern: "majority"，让聚合在多数节点未确认前就返回，结果不可靠 - 误用
allowDiskUse: true+$group组合：当新节点磁盘 I/O 不稳定时，该聚合会被路由到任意 shard 执行合并，而该 shard 可能尚未完成初始同步，直接报错
真正起效的三步实操策略
不是等扩容结束再恢复聚合，而是让聚合在扩容过程中“带伤运行”：
- 扩容前，在 mongos 层预热：对目标集合执行
db.runCommand({ analyzeShardKey: "db.coll", readWriteDistribution: true })，确认写分布无热点；若发现某字段写入占比 > 85%，暂停扩容，先调优分片键 - 扩容中，禁用 balancer 并冻结元数据：执行
sh.stopBalancer()+db.adminCommand({ flushRouterConfig: 1 })，防止 chunk 迁移与节点加入同时发生；等所有新节点状态变为SECONDARY且optimeDate落后 - 聚合语句加兜底逻辑：对关键聚合，显式加
atClusterTime参数（如{ $clusterTime: { clusterTime: Timestamp(…), signature: { hash: …, keyId: … } } }），强制所有参与节点返回 ≤ 该时间点的数据；这比依赖默认readConcern更可控
最容易被忽略的是：MongoDB 7.0 的 atClusterTime 机制只对聚合生效，且要求 mongos 版本 ≥ 7.0 —— 如果你用的是 6.x 的 mongos 连接 7.0 副本集，这个机制根本不会触发，聚合照样“时间旅行”。别只升级 server，配套组件也得同步。
