AWS DMS数据迁移异常：特定表加载失败，重启后错误扩散

一、特定表加载失败的核心排查 #

错误提示：Command failed to load data with exit error code 0 and exitwhy 1

• 表结构与约束校验
  • 逐字段对比源库与目标库该表的定义：重点核对大字段（BLOB/CLOB）、字符集（如UTF8与UTF8MB4）、主键/唯一键约束、外键依赖，确保两端兼容或完全匹配。
  • 检查表内数据：排查是否存在超大行、含不可打印字符的字符串，这类数据可能导致CSV文件生成或加载时解析失败。
• 数据量与加载压力调整
  • 若表数据量达千万级以上，尝试降低CommitRate参数（默认10000），减少每次提交的行数，避免事务过载。
  • 临时开启SkipLargeObjects参数测试，若能成功加载，说明大字段是问题根源，需单独制定大字段迁移策略。

二、重启任务后错误扩散的修复 #

错误提示：Failed to wait for previous run; Failed to load data from CSV file.; Handling End of table 'public'.'table' loading failed by subtask 1 thread 1

• 清理残留加载状态
  • 手动删除目标库中DMS生成的临时CSV文件（通常在目标库临时目录或指定S3路径），以及未完成加载的半持久化数据。
  • 在DMS控制台执行「重置任务」操作，清除之前的运行记录后再启动任务。
• 调整并行加载配置
  • 将MaxFullLoadSubTasks参数设置为1，禁用并行加载，避免多线程间的资源竞争或状态冲突。

三、Full Load + CDC模式下RECOVERABLE_ERROR的处理 #

错误提示：Last Error Task error notification received from subtask 0, thread 0 [reptask/replicationtask.c:2673] [1022502] Stop Reason RECOVERABLE_ERROR Error Level RECOVERABLE

• 查看底层错误日志
  • 前往CloudWatch日志组，定位该DMS任务的日志流，找到subtask 0 thread 0的具体错误堆栈。1022502是通用可恢复错误，底层原因多为源库日志异常、变更数据冲突或权限不足。
• 校验CDC配置有效性
  • 确认源库二进制日志（MySQL）或归档日志（PostgreSQL）已开启且未被清理，DMS账号拥有读取日志的权限。
  • 若为重启后的CDC任务，将起始位置设置为「从上次停止点继续」，避免重复捕获已加载数据导致冲突。

四、额外验证步骤 #

• 单独测试特定表：创建仅包含问题表的测试迁移任务，排除其他表干扰，验证是否能成功加载，以此区分是表本身问题还是全局配置问题。
• 权限二次校验：确认源库DMS账号拥有SELECT、REPLICATION SLAVE（MySQL）或LOGIN、REPLICATION CLIENT（PostgreSQL）权限；目标库账号拥有CREATE、INSERT、UPDATE权限，包括对临时对象的操作权限。
• 事务超时参数适配：虽已将超时时间调至1200，可进一步测试提升至1800，同时检查目标库的事务超时设置（如PostgreSQL的idle_in_transaction_session_timeout），确保两端超时时间匹配。

内容的提问来源于stack exchange，提问作者SALMAN HABIBKHAN