业务背景

在企业数据平台建设中，异构数据库迁移是常见需求。无论是国产化替代、架构升级还是多源整合，迁移的复杂度往往不在数据复制本身，而在源库连通性、目标引擎匹配、DDL 影响范围、任务失败续跑等周边环节。传统方式需要在控制台、接口文档和脚本之间反复切换，运维成本高，风险不易控制。

技术挑战

企业级迁移面临几个核心挑战：

源端类型多样：MySQL、Oracle、PostgreSQL、SQL Server、ClickHouse、InfluxDB、OpenTSDB、TDengine、MongoDB、FTP/SFTP、HDFS 等各有差异。
目标引擎必须正确匹配： RELATIONAL 与 TIMESERIES 不能混用。
DDL 操作具有破坏性：覆盖或修改目标对象前需要明确的确认机制。
失败恢复与一致性验证困难：任务失败后续跑复杂，迁移结果往往依赖人工核对。

KaiwuDB 社区版 KWDB 的 kwdb-data-migration Skill，通过 AI Agent 与 KDTS（KaiwuDB 数据迁移工具）REST API 协同，将迁移流程标准化为状态机。

收集参数 → 验证配置 → 测试两端连接 → 读取元数据 → 预览 DDL → 等待确认 → 执行 DDL → 生成并提交迁移任务 → 持续监控结果

该 Skill 支持四种迁移模式：

表数量较多时，系统按批提交，默认每批 10 个脚本，避免客户端读取超时。

兼容性校验会在任务提交前完成。源类型与目标引擎的主要约束如下：

源端类型	目标引擎要求	迁移前关注点
MySQL、Oracle、PostgreSQL、SQL Server、ClickHouse	根据数据模型选择并验证目标引擎	字段类型映射、DDL 兼容性、对象依赖
InfluxDB、OpenTSDB、TDengine	`TIMESERIES`	时间列、TAG、PRIMARY TAG 映射
MongoDB	`TIMESERIES`	文档字段展开与时序模型映射
FTP/SFTP、HDFS	`TIMESERIES`	文件格式、字段结构、时间列与标签配置

高风险操作设置确认门。执行 DDL 前展示 DDL 语句、对象清单及覆盖风险；终止迁移前展示任务状态与进度，要求输入 YES 确认。迁移前提醒备份，最终验证由用户比对行数确认一致性。

连接测试为必经步骤。系统先通过 ConfigValidator.validate_source_config() 检查源端能力，再分别测试源端和目标端连通性。

KDTS 特殊响应：部分校验失败会返回 code = 0，失败信息位于 data 字段。API 客户端会将其规整为 code = 2001，调用方不能只按普通成功码逻辑判断。

时序迁移需要指定时间列、普通 TAG 和 PRIMARY TAG。关键校验规则如下：

源数据主标签列有空值时，迁移任务可能在运行时失败。迁移前应回填数据、调整标签选择，或将该字段降级为普通 TAG。

该 Skill 将迁移细节在恰当时机逐步处理，降低了企业迁移的运维门槛和风险。首次迁移建议先执行 Schema-only 模式，核对 DDL 无误后再执行数据迁移，便于精准定位问题。

实践建议：先验证连接与类型映射，再预览并确认 DDL；完成小批量数据试迁移和行数核对后，最后扩大任务范围。