Apache Airflow数据库迁移

好好的一个周末被这厮活活的给整没了，起因是需要对airflow的数据库进行迁移。由于之前对它也没有过多的研究，数据库迁移完成之后看到dag_run表有新数据写入，进程也看到有执行，web站点看起来也是好的，就以为一切OK了。谁知周六收到统计脚本都没有执行，于是开始排查原因：

首先看到的现象是，进程有启动，CPU和之前对比没有异常，但程序没有正常执行，程序日志显示：

[2020-11-29 11:07:34,544] {taskinstance.py:624} INFO - Dependencies not met for 
<TaskInstance: xxx.xx 2020-11-27T21:20:00+08:00 [scheduled]>, dependency 'Task Instance State' FAILED: 
Task is in the 'scheduled' state which is not a valid state for execution. 
The task must be cleared in order to be run.

[2020-11-29 11:07:34,548] {logging_mixin.py:112} INFO - [2020-11-29 11:07:34,548] 
{local_task_job.py:91} INFO - Task is not able to be run

网上查到的解决方法是执行：airflow clear dag_id，尝试过发现不行，还有点误导。想着先切回到原有数据库，于是晚上就切回到原有数据库了，看到CPU基本飚满，任务也有执行的了，想着就慢慢执行呗。

第二天早上发现27号的数据还是未能正常写入，CPU一直是满的，查看日志也出现上面的日志，Web管理站点上看状态有些任务一直处于Running状态，但实际服务端没有在执行的进程，看起来切回到原始库也无法正常工作了。

想着反正也有切换新库，就把新库的dag_run、job、task_instance、log表的数据清空了，基本就是只留下了dag配置，相当于初始一个新的数据表。结果还是不那么美好，这个时候发现创建的任务和从很久以前的时间开始执行，排查到会从dags指定的时间开始重新生成任务：

'start_date': datetime(2019,12,1,0,0),

比如这个时间，Job是每5分钟执行，他就从去年12月份开始生成任务，每5分钟一个，把过往的执行过程在经历一遍。但显然这个时间程序没有接收的话，应当无法正确的处理。所以针对任务的这个时间可以指定个动态的时间：

'start_date': airflow.utils.dates.days_ago(0),

这个是需要调整的地方，但在新库上尝试初始化数据库的操作没行通，切回到老库，尝试手动删除指定dag_id对应的几个表的记录，数据也不行，但在这个过程中28号的数据执行了，也就是他还是能执行一些任务的。于是就在这个过程中徘徊了一段时间，大概就是：

日志说不能运行，CPU是跑满的，有些任务能执行success，但跑着跑着后面的任务又一直Running了。

在一段沉思之后，分析：

• 新初始化的数据库不行
• 28号数据生成了，说明有一些任务可以正常执行
• 脚本运行后日志显示执行不了

而且配置的dag数量和脚本也比较多，怀疑是调度的任务量太多，导致airflow无法正常的调度， 尝试当一个全新的任务依次配置试试。

• 1、停掉所有的任务
• 2、停掉服务
• 3、备份后清空对应的几张表

服务正常启动，逐步去打开，发现任务生成和执行都正常，多开几个，会发现有任务进行等待，依次操作后恢复正常了。那回到前面的现状上应该是同时执行的任务过多，airflow调度无法适配任务的执行频率，就会出现等待的情况，这个差异如果过大，那就可能是无法正常服务了。

周一，查看调度正常，但还是需要进行数据库迁移，本以为只是调度量的问题，切换到新库后还是不行，任务状态一直处于Running状态，经同事提醒可能是MYSQL参数explicit_defaults_for_timestamp的问题，查找貌似在airflow初始化的过程中会有提示：

Exception: Global variable explicit_defaults_for_timestamp needs to be on (1) for mysql

另外，这个参数对版本有要求，在加上之前测试新库（5.1版本）出现过datetime(6)类型不支持的情况，也出现过服务无法启动的情况，报SQL执行问题。最后切换到另一5.6的机器，同时开启explicit_defaults_for_timestamp参数后完成迁移。

所以，总结下来大概是这样子：

1、新库版本和配置问题导致迁移后无法正常运行

2、切回老库后由于时差原因，中间的调度量会重新执行，由于调度量较大导致紊乱

关于任务调度，国产的xxl-job貌似也是一种选择。