Airflow+Docker+Redshift任务报错但Redshift端查询实际执行成功

你碰到的5分钟固定时点断连、任务卡Running本质是两层问题叠加：

• 5分钟断连问题：Docker部署的Airflow与Redshift之间的网络链路存在300秒（5分钟）的TCP空闲超时规则，通常是Docker网络、VPC NAT网关、安全组或中间代理的默认配置。Redshift执行30分钟UNLOAD导出的过程中，同步连接上没有任何业务数据传输，到达5分钟阈值就会被中间设备强行断开。你看到的两个报错都是连接被断开后的上层驱动表现：struct.error: unpack_from requires a buffer of at least 5 bytes是Python Postgres驱动读取残缺缓冲区抛出的错误，psycopg2.operationalerror: ssl syscall error: eof detected是SSL层检测到连接意外关闭的标准报错。Jupyter环境不在这套Docker网络链路内，所以跑相同代码不会触发断连。
• 任务卡Running问题：自行编写Psycopg2逻辑时依然沿用同步等待查询返回的模式，要么连接处于半断开状态导致进程卡在IO等待永远不会到达的响应，要么没有主动到Redshift侧校验查询执行状态，所以Redshift端任务跑完后Airflow侧收不到结束信号，会一直停留在Running状态。
• 补充逻辑：Redshift收到UNLOAD请求后会独立执行查询，不会因为客户端连接断开就终止任务，因此会出现Airflow侧报错、但Redshift端导出依然能成功执行的现象。

按改动成本从低到高提供三个可直接落地的选项：

选项1：增加TCP保活配置，沿用同步算子（改动最小） #

不需要替换现有算子，只要让连接在查询执行期间定期发送保活包，就能避开5分钟空闲断连规则：

1. 给Redshift连接增加Psycopg2原生保活参数，在连接配置的额外参数中加入如下配置：

{
    "keepalives": 1,
    "keepalives_idle": 60,
    "keepalives_interval": 10,
    "keepalives_count": 5
}

该配置会让连接每60秒发送一次保活探针，间隔远小于5分钟超时阈值，不会被中间设备强行断开。
2. 如果配置完仍偶发断连，就将Docker守护进程、Airflow worker容器的内核TCP参数、链路中所有网络设备的空闲超时统一调整到3600秒以上，预留足够冗余。

选项2：改用异步提交+轮询模式（稳定性最高，生产环境推荐） #

完全绕开长连接超时问题，不需要调整任何网络配置：

1. 放弃同步阻塞等待UNLOAD执行完成的逻辑，提交UNLOAD语句后立刻获取对应的Redshift查询ID，将查询ID存入XCom就结束当前步骤，不需要等待查询结果。
2. 后续通过短连接定期轮询Redshift系统表，每次轮询新建连接，查询对应ID的执行状态：查询完成就标记任务成功，查询报错就拉取错误日志标记任务失败。轮询间隔设置为1-2分钟即可，单次连接执行时间仅几毫秒，完全不会触发空闲超时。
3. 如果使用的是8.0及以上版本的官方Redshift Airflow Provider，可直接用内置的异步Redshift算子替换原有RedshiftToS3Operator，算子已经封装好异步提交、状态轮询、错误上报全逻辑，不需要自行编写轮询代码。

兜底校验 #

无论选择哪个方案，都要增加幂等判断：提交UNLOAD前先检查目标S3路径是否已存在导出文件、Redshift侧是否已有对应查询执行成功的记录，避免任务重试时重复执行UNLOAD产生冗余数据。

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