AWS Kinesis Firehose写入Redshift时是否会覆盖表上的LOCK锁？

写入成功的原因排查 #

首先可以确定：Kinesis Firehose不具备强制打破Redshift表锁的权限和逻辑，你观测到的30分钟后写入成功的现象，不是Firehose的默认行为，问题出在锁持有环节：

• 你执行的LOCK <My-table-name>默认会申请ACCESS EXCLUSIVE级别的表锁，该锁会阻塞所有写入操作包括Firehose调用的COPY命令。但Redshift默认会对长期空闲的事务做自动回收：集群参数idle_in_transaction_session_timeout控制空闲事务的最大存活时间，不少集群的默认配置就是30分钟。超时后未结束的事务会被强制回滚，锁自动释放，此时等待中的Firehose写入任务自然就能执行成功。
• 也不排除你开启事务的会话意外断开、被管理员手动终止的可能性，都会触发锁提前释放。

Firehose遇锁时的默认行为 #

Firehose没有强制破锁的设计，遇到目标表被加锁时的完整逻辑如下：

• 发起的COPY命令会先进入Redshift的锁等待队列，不会立刻返回失败
• Firehose对单批次数据默认有最长24小时的重试窗口，重试间隔会随失败次数递增。如果在24小时窗口期内锁被释放，数据就会写入成功；如果超过24小时锁仍未释放，该批次数据会被转存到你预先配置的S3错误存储位置，标记为写入失败
• 既不会无限等待，也不会主动终止其他会话的事务来抢锁

测试方法 #

如果要复现验证该行为，可按以下步骤操作：

1. 新建Redshift会话，先调整当前会话的空闲事务超时参数，避免事务被提前回收：

-- 调整当前会话的空闲事务超时为1小时，按需调整时长即可
SET idle_in_transaction_session_timeout = '3600s';
BEGIN;
LOCK <你的测试表名称>;

2. 向对应Firehose流推送测试数据，可同时查询Redshift的SVV_LOCKS系统视图，会看到Firehose的COPY会话处于锁等待状态，直到你手动提交/回滚当前持锁事务、或会话超时后，写入才会成功。

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