空状态气流任务

Question

我在EC2上的24X大型机器上运行时遇到气流问题。在

我必须指出，并行级别是256。在

有几天，dagrun以“failed”状态结束，原因不明：

1. 有些任务的状态为“上游失败”，这不是真的，因为我们可以清楚地看到前面所有的步骤都是成功的。

2. 其他任务的状态不是'null'，它们还没有启动，它们会导致dagrun失败。

我必须注意，这两个任务的日志都是空的

下面是这些案例的tast实例详细信息：

有什么解决办法吗？在

Answer 1

当任务状态被手动更改（可能是通过“Mark Success”选项）或强制进入状态（如upstream_failed）并且任务从未在记录中接收到hostname值并且没有任何日志或PID时，就会发生这种情况

Answer 2

另一个我经历过第二种情况（“其他任务的状态不是‘null’”），是任务实例发生了变化，特别是操作符类型发生了变化。在

我希望你已经得到了答案/能够继续前进。上个月我有几次被困在这个问题上，所以我想我应该记录下我最终为解决这个问题所做的事情。在

---

示例：

• 任务实例最初是SubDag运算符的实例
• 需求导致运算符的类型从SubDag运算符更改为Python运算符
• 更改之后，Python操作符被设置为statenull

---

我所能拼凑出的结果是：

• 气流正在反省与每个任务相关的操作员
• 每个任务实例都被记录到数据库表task_instance
  • 此表有一个名为operator的属性
• 当调度程序重新检查代码时，它将查找具有正确运算符类型的task_instance；如果没有看到，它将更新关联的数据库记录，状态为state='removed'
• 当DAG随后调度时，气流

您可以通过查询查看受此流程影响的任务：

SELECT *
FROM task_instance
WHERE state = 'removed'

气流1.10的问题似乎已经解决了：

• https://github.com/apache/airflow/pull/3137/commits/db29af4ffb3d120ad55cd089a44b99feb7b8bf38

这就是说，我不能百分之百地肯定，根据提交，我可以发现，它可以解决这个问题。总的哲学似乎仍然是{a2}。在

我不喜欢这种解决方案，因为它使得在基本上是一条管道的迭代变得很困难。我使用的另一种方法是（部分地）遵循recommendations from Astronomer并“吹出”DAG历史。为此，您需要：

• 停止调度程序
• Delete the history from the dag
  • 这将导致DAG从webui中完全消失
  • 如果它没有完全消失，那么调度程序仍在运行
• 重新启动计划程序
  • 注意：如果您正在按计划运行DAG，请为它回填/捕获/运行其最新计划做好准备，因为您已经删除了历史记录
  • 如果您不想让它这样做，Astronomer的“快进DAG”建议可以应用