一、背景介绍

在数据驱动业务的大环境下，很多数据同步任务都属于长耗时作业，单次流程常常需要运行几十分钟，甚至长达数小时。在漫长的执行周期里，服务器重启、应用服务异常崩溃、网络波动等突发状况很难完全规避。

一旦同步流程中途被意外中断，往往会带来一系列麻烦：源库与目标库的数据出现不一致问题；运维人员需要登录服务器排查问题、定位失败节点，再手动发起重跑操作。整个处置过程不仅耗费人力，倘若故障恢复不够及时，还会直接影响下游报表统计、风控校验、业务对账等核心业务正常运转。

本文以MySQL单表向目标库同步的场景为例，演示ETLCloud平台中 失败重跑与 启动重跑两项实用能力。当ETL服务发生宕机重启之后，任务可以自动按之前进度继续执行，做到故障发生后尽量不用人工介入，保障数据同步作业可以跑完，维持下游业务的数据链路连续性。就算服务发生短暂中断，数据同步任务也不会就此停滞。

二、方案与流程设计

整体数据链路设计如下：「库表输入」组件从MySQL源库读取数据，经「定时器」组件制造人为延迟（用于模拟真实场景中长期运行的同步窗口），再由「库表输出」组件批量写入目标库。通过定时器刻意拉长流程运行时间，可以放大「流程执行中遭遇服务宕机」的窗口，从而清晰地演示中断后的自动恢复能力。依托平台的失败重跑与启动重跑机制，让流程在异常后无需人工介入即可续跑。

三、集成步骤实战

1.创建数据同步流程

在ETLCloud中新建一条数据传输流程，命名为「任务中断恢复」，并依次连接「库表输入→定时器→库表输出」三个节点，作为本次容错演示的载体。

流程设计：库表输入→定时器→库表输出

2.手动运行流程

点击「手动运行」，在弹出的运行参数窗口中直接点击「开始运行」，即可启动本次测试流程。

3.流程运行中模拟服务宕机

流程进入运行状态，监控面板显示当前任务状态为「运行中」，「库表输入」节点已读取40条数据，定时器正在执行中。在流程尚未结束的窗口期，于服务器上执行systemctlstoptomcat，强制停止ETLCloud服务，模拟真实的宕机中断。

4.重启服务并观察自动重跑

等待一段时间后，执行systemctlrestarttomcat重新启动服务，模拟服务恢复。服务恢复后，ETLCloud通过「启动重跑」自动检测到此前因服务中断而未完成的任务，并自动生成新的流程实例继续执行：调度记录中旧任务状态为「失败」，新任务状态为「未结束」（即正在自动重跑）。这正是标题所强调的「宕机重启后异常任务自动重跑」。

5.重跑结果验证

最终，新流程实例顺利完成，数据成功同步至目标库，任务状态显示为「成功」，证明ETLCloud在流程中断后能够自动恢复并完成全部数据写入，全程无需人工干预。

四、关键参数与配置调优

支撑上述「宕机重启后自动重跑」的两项核心配置如下（具体取值需结合业务容忍度与源、目标库承载能力调整）：

1.失败重跑（流程属性→重跑设置）：失败重跑=失败后从出错节点开始重跑；最大重跑次数=1；间隔时间=30秒。配置后，流程运行失败时将自动从出错节点续跑，重跑范围与频度均可控，避免无效重试打满系统资源。

2.启动重跑（流程属性→更多属性）：启动重跑=重跑；最大并发数=1。配置后，当ETL服务因重启等原因恢复时，平台会自动认领运行中被中断、尚未结束的流程并恢复执行——这正是「宕机重启后异常任务自动重跑」的直接开关，无需人工点选。

五、结论

本文以MySQL单表同步遭遇Tomcat宕机为实战场景，完整演示了在ETLCloud平台下，从方案与流程设计、故障模拟、自动重跑到结果验证的端到端全过程。通过 失败重跑+启动重跑的组合配置，长耗时同步任务在 ETL 服务宕机重启之后，可以自动接续原有进度完成数据同步，不会发生数据丢失，整个故障恢复过程不需要人工介入操作。

这两个功能是数据集成场景下兼顾任务高可用与数据一致性的重要手段：失败重跑，处理流程运行过程中产生的报错，支持从出错节点自动续跑；而启动重跑，则专门应对服务整体宕机重启的场景，自动接管那些被强行中断的任务。借助 ETLCloud 低代码的特性，不需要开发复杂的恢复逻辑，简单配置即可落地这套容错能力，很适合长周期运行的数据同步作业，减少运维的应急处置压力，保障下游业务的数据稳定供给。