全量同步时序集合适配不足:强制 _id 排序导致源端大量落盘,且目标端未按时序属性创建

[zhongli-james]

背景

关联 issue #992。用户全量同步大体量时序集合(单表逻辑数据 ~226GB、压缩后 ~50GB)时,源端出现 (OutOfDiskSpace) PlanExecutor error during aggregation :: Available space ... less than the required minimum of 524288000 bytes,并伴随大量 E11000 duplicate key error ... index:_id_。排查后确认磁盘触底是被 MongoShake 的全量读行为放大,而 dup则指向目标集合未被建成时序集合。当前全量链路把时序集合当普通集合处理,存在多处适配不足。

根因(均已在代码确认)

• 强制 _id 排序。collector/docsyncer/doc_reader.go:393 对所有集合无条件 findOptions.SetSort({_id:1})。时序集合(逻辑视图)没有 _id索引,服务端会把 find 改写为对底层 system.buckets 的解包聚合,再对解包后的全部测量值做阻塞排序,从而触发 allowDiskUse落盘。逻辑数据越大、full_sync.reader.collection_parallel 越高,并发排序落盘越严重,容易跌破 MongoDB 500MB 空闲底线。TS 分支目前只SetHint(nil) 并跳过 noCursorTimeout(有集合a，类型为timeseries，数据库同时中存在system.buckets.a的集合，则启动mongoshake开始同步之后，同步到该集合会报错: get next document failed: run find failed: (BadValue) error processing query: ns=dr-test.system.buckets.aTree: #897/迁移mongo的timeseries集合时报错 #784),未去掉 sort。
• 全量不按时序属性创建目标集合。collector/docsyncer/ 全量写入直接对逻辑名 BulkWrite,没有任何携带 timeseries:{...} 的createCollection。对于在 oplog 窗口之前就已存在的时序集合(sync_mode=all),没有 create DDL 可回放,目标端首次 insert会自动建成普通集合,丢失时序属性,并因此带上 id 唯一索引。
• dup 兜底对时序集合无效。collector/docsyncer/doc_executor.go:244-282 在 insert_on_dup_update=true 时把重复 insert 转成按 _id 的
  UpdateOne($set)。时序集合不支持按 _id 的任意更新,该兜底对真时序目标不可靠。

影响

• 大体量时序集合全量时源端临时磁盘暴涨,可能触发 OutOfDiskSpace,进而 panic + hypervisor 重启循环(见 同步时序集合的时候报错panic: splitter reader[DocumentReader id[0], src query[map[]]] get next document failed: run find failed: (OutOfDiskSpace) #992)。
• 目标端时序集合可能被降级为普通集合;重启重跑时产生大量 E11000 告警,且兜底修复在真时序目标上不成立。

建议方案(分阶段)

Phase 1 —— 快速止血,低风险:

• 全量读时序集合时不设置 _id 排序(改为自然顺序扫描)。全量同步不依赖 _id 有序,自然顺序即可消除服务端阻塞排序与落盘。
• 时序集合强制 full_sync.reader.parallel_thread=1(splitVector 依赖索引,TS 无 _id 索引不适用并发分片读)。
• 在文档/日志中提示:大体量时序全量对源端读节点(注意 secondaryPreferred 命中的是从节点)有临时空间要求。

Phase 2 —— 正确性适配,后续跟进:

• 全量开始前,若目标端不存在,按源端 timeseries选项(timeField/metaField/granularity/expireAfterSeconds)创建时序集合,避免被降级为普通集合。
• 评估对时序集合改为直接读写 system.buckets.*(bucket 天然有 _id,可廉价扫描/排序,写入保留原 bucket 结构),与增量链路已有的system.buckets 处理保持一致,实现忠实复制。
• 时序目标集合不使用按 _id 的 insert_on_dup_update 兜底;改为「保证目标干净 + 单趟不中断」或基于 bucket 幂等的策略。

验证建议

• 大体量时序集合全量:对比开启/关闭 _id 排序时源端读节点 dbPath/_tmp 落盘峰值与耗时。
• 预存时序集合 sync_mode=all:确认目标端被建成时序集合(db.getCollectionInfos 含 timeseries),且无 id 索引、无 E11000。
• 崩溃重启重跑:确认时序集合重放不因 dup 兜底失败而 panic。

相关:#992、#897、#784