变更流中断本质是底层元数据或连接状态不一致导致的“假死”，常见于config数据过期、分片不可达或迁移卡住后游标初始化失败；config过期会触发stale config detected错误，仅影响新游标，重启对应mongos或执行sh.stopbalancer()/sh.startbalancer()可恢复。
变更流中断通常不是流本身挂了，而是底层元数据或连接状态不一致导致的“假死”——比如 config 数据过期、分片不可达、或迁移卡住后游标初始化失败。
config 数据过期引发 stale config detected 错误
这是最常见的变更流中断表象。当某个 mongos 实例缓存的集群元数据（如 config.shards、config.chunks）没及时更新，执行 watch() 时就会报 could not initialize cursor across all shards because : stale config detected。
- 不是所有
mongos都会同时出问题，只影响连接到该实例的客户端 - 重启单个
mongos通常能立即恢复（它启动时会强制重拉 config 数据） - 更稳妥的做法是：在任意
mongos上运行sh.stopBalancer()+sh.startBalancer()，触发全量元数据刷新 - 注意：该错误不会导致已建立的变更流自动断开，只影响新创建的游标
目标分片宕机导致变更流无法初始化游标
变更流依赖所有分片都可路由。如果某个分片副本集全体不可达（比如 rs.status() 显示 stateStr: "DOWN"），即使其他分片正常，db.collection.watch() 也会卡在初始化阶段或直接失败。
- 检查每个分片的健康状态：
sh.status()中看shards列表下各分片是否标记为OK - 重点查
config.shards里记录的分片 host 是否真实可达（用mongo --host <shard-host></shard-host>手动连一下） - 若分片临时失联但能恢复，等它重新加入副本集并完成同步即可；若已永久失效，必须先清理
config.migrations和孤儿 chunk，否则变更流始终无法跨 shard 初始化 - 不要跳过
cleanupOrphaned—— 它修复的是“元数据说 chunk 在 A 分片，但 A 分片上查不到”，这种不一致会让变更流拒绝路由到该分片
resharding 过程中变更流事件丢失或重复
MongoDB 6.0.14+ 支持 reshardCollection 事件，但前提是开启 showExpandedEvents: true。如果变更流突然“跳过”某段时间的变更，大概率是 resharding 正在进行中，且事件未被显式启用。
- 确认变更流是否使用了扩展事件：
db.collection.watch([], { showExpandedEvents: true }) - resharding 期间，
operationDescription.reshardUUID字段唯一标识一次操作，可用于追踪进度 - 注意：resharding 不会中断已有变更流，但新事件类型（如
reshardCollection）只有开启扩展才可见 - 如果 resharding 卡在
commitChunkMove阶段，变更流可能持续返回空结果或超时——本质仍是元数据不一致，需按前两节方法清理
真正难排查的点往往不在变更流 API 本身，而在它背后依赖的集群拓扑一致性。一个 config.migrations 里残留的 "state": "committing" 记录，就足以让所有新游标初始化失败，且错误日志里不会直接提示这个根源。
