AWS DMS MySQL到PostgreSQL CDC阶段UUID类型转换失败求助

问题根源推测 #

DMS在CDC捕获MySQL的VARCHAR(36) UUID字符串时，因内部编码解析或字段处理逻辑异常，将连续的UUID字符串拆分为字符间带空格的格式，导致PostgreSQL的UUID类型无法解析。历史迁移阶段因全量读取的处理逻辑与CDC不同，因此未触发该问题。

针对性解决方案 #

1. 配置DMS列转换规则（推荐） #

直接在DMS任务的表映射中添加字段转换规则，先清理空格再转换为UUID类型：

• 编辑DMS任务的Table Mapping，在transformations数组中新增规则：

{
  "rule-type": "transformation",
  "rule-id": "UUID_Conversion_Rule",
  "rule-name": "Clean UUID string and convert to PostgreSQL UUID",
  "rule-action": "convert",
  "rule-target": "column",
  "object-locator": {
    "schema-name": "你的源MySQL schema名",
    "table-name": "tableA",
    "column-name": "user_id"
  },
  "data-type": {
    "type": "uuid"
  },
  "expression": "$REPLACE($$, ' ', '')"
}

该规则会先去除源字段的所有空格，再转换为PostgreSQL的UUID类型，从根源解决格式异常问题。

2. 统一端点字符编码配置 #

检查并调整源/目标端点的字符编码，避免因编码不匹配导致的字符串解析异常：

• 源MySQL端点：将CharacterSetName设置为utf8mb4，并在ExtraConnectionAttributes中添加charset=utf8mb4；
• 目标PostgreSQL端点：将CharacterSetName设置为UTF8，并在ExtraConnectionAttributes中添加client_encoding=UTF8；
• 重启DMS任务后测试CDC同步。

3. 临时应急方案（适合小表） #

若上述配置无法立即生效，可先临时调整目标表字段类型，待数据清理后再恢复：

1. 将PostgreSQL目标表的user_id字段临时改为VARCHAR(36)；
2. 等待CDC同步完成后，执行清理语句：

UPDATE tableB SET user_id = REPLACE(user_id, ' ', '')::UUID;

3. 将user_id字段改回UUID类型，后续同步使用方案1或2保障正常。

备选方案的风险说明 #

• 触发器执行异常语句：容易引发循环触发、数据不一致问题，且无法从根源解决格式异常，仅能临时绕过，不推荐长期使用；
• Debezium自定义转换：增加架构复杂度与维护成本，需要额外部署与监控组件，不如直接通过DMS内置规则解决高效。

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