Redshift UNLOAD/COPY迁移失败：数据损坏与stl_load

Redshift UNLOAD/COPY迁移失败：数据损坏与stl_load_errors报错排查求助

阿华AIGC实验室

2026-5-28

排查Redshift UNLOAD+COPY迁移中的数据加载错误

从你提供的stl_load_errors查询结果和迁移场景来看，这些加载错误大概率和UNLOAD的参数配置、数据导出格式，或者UNLOAD与COPY参数不匹配有关。咱们先把你查到的错误信息整理清楚，再一步步分析解决：

执行语句：

select distinct err_reason from stl_load_errors;

返回的错误类型：

这是跨集群迁移最容易踩的坑：

分隔符与转义配置：如果UNLOAD用了自定义分隔符（比如DELIMITER '|'），但数据中存在相同的字符且未开启转义，就会导致COPY时出现Delimiter not found错误。建议：
- 选择一个数据中绝对不会出现的分隔符（比如DELIMITER '\t'）
- 配合ESCAPE '\'参数，确保特殊字符被正确转义
- 如果用CSV格式，UNLOAD时加上ADDQUOTES，COPY时对应设置QUOTE '"'，避免字符串中的特殊字符干扰字段拆分
NULL值处理：Missing data for not-null field可能是因为UNLOAD导出的NULL值格式不被COPY识别。比如UNLOAD默认会把NULL导出为空字符串，但如果目标表字段是非空的，COPY会认为数据缺失。建议在UNLOAD和COPY中统一设置NULL AS '\\N'，确保NULL值被正确识别。
字段顺序与表结构一致性：很多Invalid digit错误是因为字段错位导致的——比如原本是字符串字段的内容被COPY到了数值型字段中。请确认源表和目标表的字段顺序、类型完全一致，UNLOAD时没有指定错误的字段列表。

数值类型错误（Invalid digit）：比如Value 'e'出现在Integer字段中，大概率是字段拆分错误（分隔符问题），或者源表中该字段本身就有非数值数据（但你是同结构迁移，这种情况概率低）。可以下载S3上的UNLOAD文件，查看错误行的具体内容，确认是不是字段错位导致的。
字符串长度超限：String length exceeds DDL length说明源表中某些字符串的长度超过了目标表对应字段的定义。请核对源表和目标表的字段长度（比如VARCHAR(50) vs VARCHAR(30)），如果是目标表定义过短，需要先调整目标表结构。
通用Invalid data：这类错误通常是数据格式与COPY预期不匹配，比如日期格式错误、布尔值格式不统一等。可以结合stl_load_errors中的line_number和filename字段，定位到具体错误行分析。

直接查看S3上的导出文件是最直观的排查方式：

用AWS CLI下载一小部分文件到本地：aws s3 cp s3://your-unload-path/part-00000 .
用文本编辑器或cat/head命令查看内容，检查：
- 每行的字段数是否和表列数一致
- 数值字段是否都是合法的数值（没有非数字字符）
- 字符串是否被正确引号包裹（如果开启了ADDQUOTES）
- NULL值是否按照预期格式导出