dts不支持异构数据库原生增量同步，因其增量能力仅兼容mysql binlog、oracle redo log等标准日志格式；tidb需pump/drainer+kafka中转，mongodb仅支持有限操作，db2无增量通道，sql server增量依赖cdc且版本受限。
不能直接用 DTS 对异构数据库（如 TiDB、MongoDB、Db2、SQL Server）做「纯增量同步」到 MySQL，必须分两步：先全量迁移完成，再基于特定组件或协议开启增量捕获。DTS 本身不解析异构库的原生日志（比如 TiDB 的 TiKV Raft log、MongoDB 的 oplog、Db2 的 UOW 日志），它依赖中间适配层或源库暴露的标准变更流。
为什么 DTS 不支持异构库的原生增量同步？
DTS 的增量能力本质是「日志订阅」，只兼容 MySQL Binlog、Oracle Redo Log、PostgreSQL WAL、SQL Server CDC/Transaction Log 等明确格式的日志。而 TiDB、MongoDB、Db2 等数据库：
- TiDB 的 Binlog 是 Pump/Drainer 构建的伪 Binlog，需额外部署 Kafka + Pump + Drainer 才能被 DTS 识别为「Kafka 源」
- MongoDB 的 oplog 是 BSON 格式，DTS 不直接消费；必须通过 DTS 内置的 MongoDB Reader（仅支持 insert/update/delete）拉取变更，且
update仅限$set类型 - Db2、SQL Server 等虽有日志机制，但 DTS 对 Db2 仅支持全量迁移，无增量通道；SQL Server 增量依赖开启 CDC 或事务日志备份模式，且仅限企业版
TiDB → RDS MySQL 增量迁移的实际路径
必须引入 Pump/Drainer + Kafka 中转，DTS 只作为 Kafka → MySQL 的消费者：
- 确保源 TiDB 已启用
pump并配置drainer输出到 Kafka Topic（如tikv_binlog） - 目标 RDS MySQL 实例所在地域必须在 DTS 支持列表中（如华东1、华北2、深圳等），否则无法选择「Kafka 作为源」
- DTS 任务类型选「Kafka 到 MySQL」，不是「TiDB 到 MySQL」；Topic 名、Kafka 认证信息、起始 Offset 需与 Drainer 输出严格对齐
-
drainer的syncer.db-type必须设为mysql，否则输出的 JSON 结构 DTS 无法解析
MongoDB → RDS MySQL 增量同步的关键限制
DTS 虽支持 MongoDB 作为源，但增量能力极弱，容易因数据结构误判失败：
- 仅同步
insert、update（仅$set）、delete三类操作；$unset、$inc、数组更新等全部丢弃 - 目标 MySQL 表必须提前建好，且字段名需与 MongoDB 文档 key 完全一致（区分大小写），否则
update会写入空值 - 若源集合存在嵌套文档（如
address.city），DTS 默认展平为address_city，但不会自动建对应字段——需人工补全目标表 schema - 全量迁移未完成前，不能开启增量；DTS 会等全量 checksum 校验通过后才启动增量拉取线程
Db2 / SQL Server → MySQL 的增量替代方案
DTS 对 Db2 无增量支持；SQL Server 增量仅限开启 CDC 的表，且要求：
- 源 SQL Server 实例为 2016+ 企业版或标准版（2022 起标准版也支持 CDC）
- 需手动为每张待同步表执行
sys.sp_cdc_enable_table，DTS 不自动启用 - 目标 MySQL 表主键必须与源表一致，否则
update/delete无法定位行，导致数据错乱 - 若使用事务日志备份方式，
log backup频率必须 ≤ DTS 增量拉取间隔，否则日志被截断导致断点续传失败
真正麻烦的不是配置按钮点哪，而是确认源库有没有提供 DTS 能吃的“日志格式”——没有，就得自己搭中继（比如 Debezium + Kafka），DTS 只负责最后一公里。很多团队卡在 Pump 同步延迟或 MongoDB 字段映射失败上，不是因为不会点控制台，而是没看清 DTS 的能力边界在哪。
