GCP Composer Airflow中mysql_to_gcs处理大表时触发negsignal.sigkill报错

首先要明确：任务报negsignal.sigkill意味着进程是被操作系统层面强制终止的，不是Airflow算子本身抛出的逻辑异常——这也是为啥你除了这个提示找不到任何业务日志的原因，进程被硬杀时根本来不及输出异常栈。
结合你“小表全流程正常、大表任务数秒就失败、提升Composer集群容量也没解决问题”的场景，这个故障90%以上是OOM触发内核进程杀掉机制导致的，几个很多人踩过的认知坑可以直接对照：

• 很多人调整Composer集群容量时，只改了集群节点的整体配置，没注意Airflow Worker Pod本身有单独的固定内存上限。哪怕集群节点剩了几十G的空闲内存，只要单个Worker进程占用的内存超过给这个Pod设的内存limit，内核会立刻把这个进程杀掉，和集群整体剩多少资源没有关系——这就是你升了集群容量问题还没解决的核心原因。
• mysql_to_gcs算子默认的工作逻辑是一次性把MySQL查询结果全量拉到Worker进程内存里，再分片写入GCS，根本不是流式传输。100Mb以内的小表全量加载到内存完全扛得住，但几G到10G级别的表，光把原始查询结果加载到内存就要占好几G，刚好碰到默认Worker的内存上限，进程刚启动拉几秒数据就被干掉，自然啥有价值的日志都留不下。
• 还有容易被忽略的连带问题：默认的MySQL客户端连接是会把整个结果集全缓存在客户端内存里的，哪怕你表本身只有几个G，如果写的SQL是不带索引的多表JOIN、或者查了很多没用的大字段，实际返回给Worker的结果集可能是原表大小的好几倍，直接触碰内存阈值。

• 第一步做快速验证：直接把运行mysql_to_gcs任务的Worker Pod内存上限临时调高，比如从默认的2Gi提到8Gi，重新跑之前失败的大表任务。如果任务能正常出结果，就100%坐实是内存触限被kill的问题，不用再浪费时间去排查Cloud SQL连接、网络连通性、算子代码逻辑这些方向。
• 第二步从根源降低任务内存占用，避免碰到更大的表再出同类问题：
  • 修改MySQL连接配置，给连接加上流式读取的参数，让MySQL驱动逐行从服务端拉取结果，不再把全量结果集缓存在Worker内存里。这种模式下哪怕是100G级别的大表，Worker的内存占用也能稳定控制在几十Mb级别，基本不会触发OOM。
  • 调整mysql_to_gcs的分片写入参数，把单批次写入GCS的行大小限制在合理范围，配合流式读取进一步压低瞬时内存峰值。
• 第三步补个兜底检查：
  • 查一下大表任务的SQL执行计划，确认没有因为缺索引导致查询返回的结果集远大于实际表大小的情况。
  • 对超过5G的超大表，别硬用单任务全量拉，按分区或者分片把任务拆成几个小任务并行跑，进一步降低单任务的内存压力。
  • 别把资源调整的方向搞反：这个场景下的瓶颈是内存，不是CPU、不是磁盘、不是带宽，盲目给Worker加CPU核数对解决sigkill问题没有任何作用，优先把内存配额调到匹配任务结果集大小的范围才是核心。

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