自托管Airflow迁移至Cloud Composer 2：DAG运行历史迁移方法咨询

核心思路 #

Airflow的DAG运行历史存储在元数据库（通常为PostgreSQL/MySQL）中，迁移本质是将自托管环境元数据库内的运行相关表数据导出，再导入到Cloud Composer 2的元数据库实例中。目前官方没有一键迁移工具，但可通过手动步骤完成。

具体操作步骤 #

1. 导出自托管Airflow的运行元数据 #

先确认自托管Airflow的元数据库类型，针对性导出核心运行历史表：

• PostgreSQL环境：使用pg_dump导出dag_run（DAG运行记录）、task_instance（任务实例记录）、log（运行日志）、xcom（跨任务数据）、job（调度任务记录）等表：

  pg_dump -h <自托管DB主机地址> -U <数据库用户名> -d <Airflow元数据库名> -t dag_run -t task_instance -t log -t xcom -t job -f airflow_history_dump.sql
  

• MySQL环境：使用mysqldump导出对应表：

  mysqldump -h <自托管DB主机地址> -u <数据库用户名> -p <Airflow元数据库名> dag_run task_instance log xcom job > airflow_history_dump.sql
  

注意：不要导出dag表，Cloud Composer的DAG需通过代码仓库同步，避免表数据冲突。

2. 配置Cloud Composer元数据库访问权限 #

Cloud Composer 2的元数据库是Google Cloud SQL实例，需先完成访问配置：

• 在GCP控制台的Composer环境详情页，找到「数据库」模块获取连接字符串；
• 开启Cloud SQL实例的IP授权（添加你的操作机器IP）或通过VPC私网访问，确保能连接到目标数据库。

3. 导入数据到Cloud Composer元数据库 #

连接到Cloud Composer的元数据库，执行数据导入：

• PostgreSQL环境：

  psql -h <Composer DB主机地址> -U <数据库用户名> -d <Composer元数据库名> -f airflow_history_dump.sql
  

• MySQL环境：

  mysql -h <Composer DB主机地址> -u <数据库用户名> -p <Composer元数据库名> < airflow_history_dump.sql
  

导入前需确认：自托管Airflow版本与Cloud Composer的Airflow版本尽量一致（如均为2.x同小版本），避免表结构差异导致导入失败；导入后可按需调整dag_run中的start_date等字段，匹配Composer环境的时间设置。

4. 验证迁移结果 #

登录Cloud Composer的Airflow UI，进入对应DAG的「历史」标签页，确认旧运行记录、任务状态、日志是否正常展示；可触发测试DAG，验证新老运行记录共存无冲突。

关键注意事项 #

• 版本兼容性：若自托管与Composer的Airflow版本差异较大（如自托管2.0 vs Composer2.5），需先在本地升级自托管元数据库结构，再导出数据，或参考Airflow版本迁移文档调整SQL内容。
• 数据一致性：迁移前暂停自托管Airflow的调度，避免导出过程中产生新的运行记录，导致数据不一致。
• 日志迁移补充：若自托管日志存储在本地或第三方存储，需将日志文件迁移至Composer对应的Cloud Storage桶，再更新log表中的file_path字段为GCS路径（如gs://<composer-bucket>/logs/...）。
• 权限要求：操作Cloud SQL实例需具备Cloud SQL Client、Cloud SQL Editor等GCP权限，确保操作账号权限充足。

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