数据集成任务断点续传与失败重试设计

集成任务失败后能不能从断点续跑，取决于引擎有没有把"读到哪里"的进度持久化。结论：SeaTunnel 和 Flink CDC 把读取位点写进 checkpoint，失败后从 checkpoint 恢复即可续传；DataX 没有 checkpoint，重跑就是从头再跑一遍，只能用主键或时间条件过滤模拟断点，且必须先做幂等改造再谈重试。 改造顺序是固定的：先固化位点，再定重试策略，最后补幂等。

改造前先确认三件事

• 位点可捕获：源端必须能暴露读取位置，例如 MySQL binlog 的文件名与位点、Kafka 各分区的 offset、或业务表的主键与更新时间上界。位点不可捕获的源（如无主键无时间戳的全量快照表）无法实现严格断点续传。
• 主键是 CDC 断点的硬前提：以 SeaTunnel 为例，其官方 FAQ 明确不支持无主键表的 CDC 同步——源端若存在两条完全相同的数据，删除或修改其中一条时，下游无法区分该改哪一条。这类表要么在源端补主键，要么放弃增量、退回按时间窗重跑。官方列出的 CDC 源包括 MySQL、PostgreSQL、Oracle、MongoDB、SQL Server、TiDB 与 OpenGauss，选型阶段先确认源库在列。
• checkpoint 有可靠存储：checkpoint 只写在本地磁盘等于没有容错。计算节点重启或销毁后，位点必须还能从 HDFS、对象存储等外部存储读回。
• 下游具备幂等条件：断点续传的本质是"至少一次"投递，恢复后可能重放一段已写过的数据。下游若无唯一键、无覆盖写能力，重复数据会直接进入结果表。

步骤一：固化读取位点

• SeaTunnel：在任务配置中开启 checkpoint，位点随算子状态写入 checkpoint 目录。任务失败后用 -r latest 或指定 checkpoint ID 恢复，从最近一次成功 checkpoint 继续读取。
• Flink CDC：位点（binlog 位点、快照分片进度、watermark）保存在算子状态中，由 checkpoint 机制落盘。恢复时用 flink run -s 从状态路径启动。整库同步场景下，快照阶段的分片进度同样在状态里，不会因快照未完成而全量重跑。
• DataX：没有状态。所谓断点只能靠"历史水位表"模拟：记录每个任务上次成功的最大主键或最大更新时间，下次运行时把它拼进 reader 的 where 条件。水位的更新时机要和写入成功对齐，否则会漏数或重复跑。

步骤二：区分重试类型

• 可自动重试：网络连接超时、连接重置、瞬时的元数据锁等待、目标端短时不可写。这类错误应配置指数退避重试，固定间隔重试容易打满源端或目标端的连接池。
• 不可自动重试：权限失效、表结构变更导致的字段不匹配、数据类型溢出、主键冲突策略未定义、DDL 变更中断的 CDC 任务。这类错误重试没有意义，应直接告警并终止，等人工介入。
• 重试次数要有上限并配合告警。无限重试会把"一次失败"放大成"持续写错数据"。
• 判定分支建议固化成规则：错误信息含连接、超时、重置字样且源端当时正值变更高峰，按可自动重试处理；含权限、字段不存在、类型溢出、主键冲突字样，一律转人工。同一任务同一错误连续出现三次仍无法归类时，按不可自动重试处理并保留现场日志。

步骤三：幂等改造（重试的前提）

• 下游表建唯一键（业务主键或幂等键），写入用 upsert 或"先删后插"语义。
• CDC 任务必须把 INSERT、UPDATE、DELETE 三类事件都传递到下游，只同步增量插入会导致下游与源端不一致。
• 对于只能追加写入的下游（如部分日志型存储），把幂等做在消费侧：按主键去重，或按时间窗覆盖。
• 写入语义要与幂等策略对齐：以 SeaTunnel 的 JDBC Sink 为例，配置 generate_sink_sql = true 并提供 primary_keys 时，引擎自动生成 INSERT、UPSERT、UPDATE 与 DELETE，适配"下游有唯一键"的场景；只有必须逐行控制写入 SQL 时才用 query 自定义语句。两者不要同时配置，且配置了 query 后 save mode 不再生效，重跑前要单独确认。

重跑前的 save mode 检查

• 任务启动前，SeaTunnel 通过 schema_save_mode 与 data_save_mode 决定如何处理目标端结构与数据：schema_save_mode 可选 RECREATE_SCHEMA（表存在则删除重建）、CREATE_SCHEMA_WHEN_NOT_EXIST、ERROR_WHEN_SCHEMA_NOT_EXIST 与 IGNORE；data_save_mode 可选 DROP_DATA（保留结构、清空数据）、APPEND_DATA、CUSTOM_PROCESSING 与 ERROR_WHEN_DATA_EXISTS。
• 最危险的误配置，是恢复任务时仍沿用建表时的 `RECREATE_SCHEMA` 或 `DROP_DATA`：断点续传场景下这等于删表或清空下游，把"续跑"变成"重建"。恢复演练与生产恢复一律改为 CREATE_SCHEMA_WHEN_NOT_EXIST 加 APPEND_DATA，或用 CUSTOM_PROCESSING 指定安全动作。
• 定时类批任务若由系统 cron 或调度平台触发，调度侧重试参数要与引擎自身的重启策略分开配置，避免两层重试叠加，把同一批数据并发重放。

配置示例

SeaTunnel 任务开启 checkpoint 与固定延迟重启：

execution {
  parallelism = 4
  checkpoint.interval = 60000
}

state {
  backend = "hdfs"
  checkpoints.dir = "hdfs:///tmp/seatunnel/checkpoints"
}

restart-strategy = "fixed-delay"
restart-strategy.max-attempts = "10"
restart-strategy.delay = "10s"

从最近一次 checkpoint 恢复任务：

./bin/seatunnel.sh --config config-v2.conf -r latest

Flink 作业开启 checkpoint 并从状态恢复：

state.checkpoints.dir = hdfs:///tmp/flink/checkpoints
execution.checkpointing.interval = 60000

flink run -s hdfs:///tmp/flink/checkpoints/<job-id>/chk-120 flink-cdc-job.jar

DataX 用时间条件模拟断点的 reader 片段：

"reader": {
  "name": "mysqlreader",
  "parameter": {
    "connection": [{
      "table": ["orders"],
      "jdbcUrl": ["jdbc:mysql://host:3306/db"]
    }],
    "where": "update_time >= '2026-10-04 00:00:00' AND update_time < '2026-10-05 00:00:00'",
    "column": ["id", "order_no", "amount", "update_time"]
  }
}

风险与回退

• checkpoint 间隔过大：恢复后需要重放的量变大，下游重复窗口变长。间隔应结合业务能容忍的重复量与 checkpoint 耗时权衡。
• 重放量要能估算：checkpoint 间隔 60 秒时，最坏情况下的重放量约等于一分钟内的写入峰值；把间隔、单分钟写入峰值与下游去重能力放在一起评估，比只看"间隔越小越好"更可靠。
• 恢复位点选错：手动指定 checkpoint ID 时选错会跳数或重放过多。默认用 latest，排查问题时再固定 ID。
• CDC 双跑窗口：全量快照与增量 binlog 切换瞬间存在重叠，需靠主键幂等吸收。
• 无法恢复时的回退：checkpoint 丢失或源端位点被清理（如 binlog 已过期），断点续传不成立，只能按时间窗重跑，或全量重建后增量追平。
• 验证手段：恢复后对比源端与目标端在重放窗口内的行数与主键集合，确认不漏数、重复可控。

三类失败模式速查

• 位点丢了：checkpoint 目录被误清理，或恢复命令指向了错误的路径。表现为任务从更早的位点重跑，下游出现大面积重复。规避：checkpoint 存放路径纳入备份范围，恢复命令只允许从上一次成功的 checkpoint 列表中选取。
• 源端位点被清理：binlog 或日志保留期短于任务停机时间，断点续传不成立。表现为恢复时报位点不存在，或任务直接从头读起。规避：源端日志保留期至少覆盖"最长可接受停机时间"，这是源库侧的准入条件，不是集成工具能补救的。
• 下游写入不幂等：重放窗口内的数据被追加写入而非覆盖，表现为按主键去重后仍存在重复行。规避：恢复演练必须包含"同一段数据重复写一遍"的场景，而不是只验证任务能跑起来。

上线前检查清单

• 源端位点是否可持久化，checkpoint 或水位是否落在外部可靠存储
• 任务是否配置了重试上限与失败告警
• 下游表是否有唯一键与 upsert 能力
• CDC 任务是否完整传递删除事件
• 是否演练过"杀任务再恢复"，确认数据不丢不重
• 恢复后的对账口径是否明确（按主键比对还是按时间窗计数）