AWS DMS迁移Aurora MySQL时特殊字符异常问题求助

问题原因 #

1. 字符集/校对规则不匹配：源与目标Aurora MySQL实例的字符集（如utf8 vs utf8mb4）或校对规则不一致，DMS在迁移时对特殊控制字符（如ASCII 26的SUB字符）做了转义替换。
2. DMS字符集配置错误：任务未启用「保留原始字符集」选项，或目标字符集配置与源库不符，导致字符转换过程中丢失特殊字符的原始编码。
3. JSON列处理方式不当：DMS默认对JSON列做字符转义处理，而非二进制传输，不可打印的特殊字符被替换为[SUB]占位符。

解决方案 #

1. 对齐源与目标库的字符集配置 #

• 执行以下SQL分别检查源和目标库的字符集：

  SHOW CREATE DATABASE your_database_name;
  SHOW CREATE TABLE your_table_name;
  

• 确保两者的字符集统一为utf8mb4（支持完整Unicode字符），校对规则（如utf8mb4_general_ci）完全一致。若目标库不符，先调整后重新迁移。

2. 修改DMS任务的字符集设置 #

• 进入DMS任务的「任务设置」，找到Character set configuration：
  • 将Target character set设置为Same as source；
  • 启用Preserve original character set选项，禁止DMS自动转换字符集。

3. 配置JSON列的二进制传输 #

• 在DMS任务的「表映射」中，针对包含JSON列的表添加转换规则：
  • 开启Data transformation下的Convert to binary选项，让DMS以二进制模式传输JSON列，避免字符转义。
• 若为全量迁移场景，可启用Use direct table load选项，减少中间转换环节。

4. 校验特殊字符的原始编码 #

• 用十六进制对比源和目标的JSON列值，确认是否为控制字符：

  SELECT HEX(jsondata) FROM your_table_name WHERE id = your_row_id;
  

• 如果源库的?实际是ASCII控制字符（如SUB），确保上述配置生效后重新执行全量迁移+校验。

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