我之前在维护Airflow集群时也碰到过一模一样的问题——手动触发DAG后任务卡在“no status”，每次重启服务+手动标成功实在太折腾！下面是我总结的几个实用解决方案，从快速排查到长期优化都有：

一、先确认调度器与任务的基础运行状态 #

• 别着急重启服务，先看调度器日志：执行airflow scheduler logs，重点找任务接收失败、队列阻塞或者数据库连接报错的信息——很多时候是调度器没接收到DAG触发的信号，或者和元数据库断连了。
• 如果用的是CeleryExecutor，检查worker状态：执行airflow celery worker status，确认worker是否在线，有没有队列堆积。要是worker挂了，任务根本没机会被执行，自然显示“no status”。

二、排查DAG与任务的配置坑 #

• 检查start_date和schedule_interval：绝对不要用动态的datetime.now()作为start_date，建议设为过去的固定时间（比如datetime(2024, 1, 1)）。如果手动触发的时间和schedule_interval逻辑冲突，调度器可能无法生成有效的任务实例。
• 确认DAG是否被意外暂停：去Airflow UI的DAG列表里看看，你的DAG是不是处于paused状态——要是不小心暂停了，调度器会直接忽略触发请求。
• 检查任务的execution_timeout：如果任务还没开始执行就触发超时，也可能出现无状态的情况，可以临时把这个值调大（比如timedelta(minutes=10)）测试一下。

三、不用重启服务的快速修复方法 #

• 用命令行重新触发任务实例：不用手动标记成功，直接清理旧任务再重新跑：

  # 清理指定任务实例（替换成你的DAG ID、任务ID、执行日期）
  airflow tasks clear -d your_dag_id -t your_task_id -e "2024-05-20T00:00:00"
  # 重新触发任务
  airflow tasks run your_dag_id your_task_id "2024-05-20T00:00:00"
  

• 修复元数据库异常状态：如果是数据库里的任务实例状态错乱，可以直接更新task_instance表（操作前记得备份数据库）：

  -- 将异常的任务状态改为queued，让调度器重新拾取
  UPDATE task_instance 
  SET state='queued' 
  WHERE dag_id='your_dag_id' 
    AND execution_date='2024-05-20 00:00:00' 
    AND task_id='your_task_id';
  

四、长期预防的配置优化 #

• 调整dag_dir_list_interval：在airflow.cfg里把这个参数调小（比如30秒），让调度器更频繁地扫描DAG文件，避免触发信号被遗漏。
• 优化并发参数：根据你的集群资源，合理设置parallelism、dag_concurrency和worker_concurrency，避免因为并发限制导致任务无法被调度。
• 定期清理元数据库：每月执行airflow db clean清理旧的任务实例、日志和XCom数据，防止数据库表过大拖慢性能。

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