30亿条MySQL Aurora数据迁移至同集群5表及XML转JSON与故障处理方案咨询

核心疑问的直接解答 #

初步链路相关问题的明确结论 #

• LOAD DATA LOCAL中途失败的处理逻辑
  这类命令本身是事务级原子操作，执行中断时未提交的事务会自动回滚，不会产生脏数据。但通过Lambda执行时，受Lambda5分钟超时限制、执行环境网络波动影响，中断概率极高，需配套前置元数据设计：为每个待加载的S3文件分配唯一批次ID，记录文件对应的主键范围、数据校验和，存入独立的元数据表。每次执行加载前先校验元数据状态，若为失败状态，先按主键范围清空目标表可能残留的半写入数据，再重新发起加载。
• Lambda感知LOAD DATA LOCAL执行结果的机制
  直接使用MySQL客户端的同步返回能力即可：通过Lambda内嵌的同步MySQL客户端发起LOAD DATA命令时，客户端会等待数据库返回执行结果，成功时返回匹配行数、错误跳过行数，失败时直接抛出对应异常。无需额外探活逻辑，只要在代码中捕获客户端返回值与异常，把结果回写到元数据表即可。禁止在该场景下使用异步提交模式，否则Lambda回收执行环境时会导致命令执行中断、结果丢失。
• Data Pipeline替代Lambda执行LOAD DATA的可行性
  技术上完全可行，但性价比极低。Data Pipeline的执行节点为EC2实例，虽然能运行LOAD DATA命令，但调度延迟高、整体成本是Lambda的3-5倍，且缺乏细粒度的事件触发能力，对单文件处理的场景效率极差，没有使用价值。
• DMS从S3直接向Aurora加载数据的可行性
  原生能力支持。DMS可配置S3作为源终端节点，直接读取S3上的CSV、JSON格式文件，批量加载到Aurora目标表，无需自研LOAD DATA逻辑。但DMS的S3加载能力不支持自定义字段转换，因此XML转JSON的逻辑必须在进入DMS加载环节前完成。

具备完整故障处理能力的最优落地方案 #

整体链路设计如下：

源Aurora单表 --(DMS全量同步+CDC增量捕获)--> S3原始存储桶（单文件切分为100-200MB大小的CSV，每批次附带元数据：批次ID、主键范围、数据校验和）
--(S3事件触发Lambda)--> S3处理后存储桶（完成XML到JSON的字段转换，按5张目标表的拆分规则生成对应格式的导入文件，同步更新元数据表状态：已转换、待加载）
--(DMS配置S3源终端节点)--> 目标Aurora集群下的5张拆分表

该方案的故障容错能力覆盖全链路：

• 全链路状态追踪：所有批次的元数据独立存储，从DMS抽数、Lambda格式转换、DMS加载三个环节的状态（处理中、成功、失败）实时更新，任意环节失败时，仅需从对应断点重启该批次流程，无需全量重跑
• 断点续传能力：DMS同步本身支持位点续传，Lambda处理文件前先校验是否已完成转换，避免重复计算；DMS加载S3文件时会逐文件标记已加载状态，杜绝重复导入
• 一致性校验：每批次加载完成后，自动对比源端与目标端的行数、主键范围、数据校验和，发现差异自动触发该批次的重新加载
• 性能与成本优化：30亿条数据规模下，DMS的抽数、加载吞吐可达每分钟千万级，整体性能比自研Lambda跑LOAD DATA的方案高3倍以上，且无需自研连接池管理、超时重试、错误日志收集的通用逻辑，运维成本降低80%以上

内容的提问来源于stack exchange，提问作者Sudarshan kumar