Redshift从DC2切换至RA3实例类型后COPY命令触发死锁问题排查请求

问题复现 #

你提到之前在DC2实例上一直正常运行的COPY命令：

echo "COPY table_name FROM 's3://bucket/<date>/' iam_role 'arn:aws:iam::123:role/copy-iam' format as json 's3://bucket/jupath.json' gzip ACCEPTINVCHARS ' ' TRUNCATECOLUMNS TRIMBLANKS MAXERROR 3;" | psql

切换到RA3实例后，虽然数据加载成功（返回INFO: Load into table 'table_name' completed, 53465077 record(s) loaded successfully.），但随即触发死锁错误：

ERROR: deadlock detected
DETAIL: Process 26999 waits for AccessExclusiveLock on relation 3176337 of database 108036; blocked by process 26835. Process 26835 waits for ShareLock on transaction 24230722; blocked by process 26999.

且你确认当前只有这一个进程对目标表操作，唯一的环境变更就是实例类型从DC2切换到RA3。

原因分析 #

RA3和DC2的核心差异在于存储架构：DC2是本地存储+计算一体化，而RA3采用计算与存储分离（数据存储在S3，计算节点挂载访问）。这种架构变化会带来一些内部机制的不同，其中就包括锁的管理和后台存储相关进程的行为：

• RA3实例会有后台进程负责数据快照、存储层同步、元数据维护等操作，这些进程可能会在你执行COPY时对目标表发起锁请求，从而和你的COPY进程形成死锁。
• 即使你没有手动触发其他操作，Redshift的自动维护任务（比如自动VACUUM、自动ANALYZE）在RA3上的触发逻辑或锁策略可能和DC2不同，容易和COPY操作产生冲突。

解决方案 #

1. 排查并等待后台进程完成 #

首先确认是否有后台任务在运行，占用了表的锁：

• 查询当前活跃进程：

  SELECT pid, query, status, starttime FROM stv_recents WHERE status = 'Running';
  

• 检查自动VACUUM/ANALYZE的进度：

  -- 查看VACUUM进度
  SELECT * FROM svv_vacuum_progress;
  -- 查看ANALYZE进度
  SELECT * FROM svv_analyze_progress;
  

如果发现有后台维护任务在运行，等待其完成后再执行COPY命令即可。如果需要临时规避，可以先禁用目标表的自动维护（执行完COPY后记得重新开启）：

ALTER TABLE table_name SET (autovacuum_enabled = false);
ALTER TABLE table_name SET (autoanalyze_enabled = false);

2. 手动控制锁策略 #

尝试在COPY前手动对表加锁，避免和后台进程的锁请求冲突：

# 先执行锁命令，再执行COPY
echo "LOCK TABLE table_name IN SHARE MODE; COPY table_name FROM 's3://bucket/<date>/' iam_role 'arn:aws:iam::123:role/copy-iam' format as json 's3://bucket/jupath.json' gzip ACCEPTINVCHARS ' ' TRUNCATECOLUMNS TRIMBLANKS MAXERROR 3;" | psql

ShareLock级别不会阻止其他只读操作，但会阻止排他锁请求，能减少死锁发生的概率。如果还是有问题，可以尝试升级锁级别到SHARE ROW EXCLUSIVE MODE，但注意不要过度锁表影响其他潜在操作。

3. 检查残留事务与表状态 #

查看报错中提到的事务（transaction 24230722）是否有残留：

SELECT * FROM stv_transactions WHERE xid = 24230722;

如果发现该事务未正常结束，可以联系AWS支持协助清理，或者尝试重启实例（谨慎操作，避免影响业务）。另外，手动更新表的统计信息也有助于RA3实例更好地管理表资源：

ANALYZE table_name;

4. 调整COPY执行时机 #

RA3的后台存储操作（比如快照、数据归档）通常会在低峰期自动触发，尽量在业务低峰期执行COPY命令，避免和这些后台任务撞期。

总结 #

这个问题本质上是RA3架构带来的内部机制变化导致的锁冲突，并非COPY命令本身的问题。通过排查后台任务、调整锁策略或执行时机，基本可以解决这类死锁问题。

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