Para aproveitar ainda mais o sucesso e a crescente preferência dos clientes por soluções de código aberto, o Cloud Composer está evoluindo para se tornar o Serviço gerenciado para Apache Airflow. Essa mudança de nome melhora o entendimento do cliente sobre nosso portfólio e reforça nosso compromisso de ser o ecossistema de nuvem mais aberto.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Migrar ambientes para o Airflow 3 (lado a lado)

Airflow gerenciado (Geração 3) | Airflow gerenciado (Geração 2) | Airflow gerenciado (Geração 1 legada)

Nesta página, explicamos como transferir DAGs, dados e configurações do ambiente atual do Airflow Gerenciado (Geração 3) com o Airflow 2 para um ambiente do Airflow Gerenciado (Geração 3) com o Airflow 3.

Outros guias de migração

De	Para	Método	Guia
Airflow gerenciado (Geração 3), Airflow 2	Airflow gerenciado (Geração 3), Airflow 3	Lado a lado, transferência manual	Este guia
Airflow gerenciado (Geração 2)	Airflow gerenciado (Geração 3)	Lado a lado, usando o script de migração	Guia de migração de scripts
Airflow gerenciado (Geração 2)	Airflow gerenciado (Geração 3)	Lado a lado, usando snapshots	Guia de migração de snapshots
Airflow gerenciado (Geração 1 legada), Airflow 2	Airflow gerenciado (Geração 3)	Lado a lado, usando snapshots	Guia de migração de snapshots
Airflow gerenciado (Geração 1 legada), Airflow 2	Airflow gerenciado (Geração 2)	Lado a lado, usando snapshots	Guia de migração de snapshots
Airflow gerenciado (Geração 1 legada), Airflow 2	Airflow gerenciado (Geração 2)	Lado a lado, transferência manual	Guia de migração manual
Airflow gerenciado (Geração 1 legada), Airflow 1	Airflow gerenciado (Geração 2), Airflow 2	Lado a lado, usando snapshots	Guia de migração de snapshots
Airflow gerenciado (Geração 1 legada), Airflow 1	Airflow gerenciado (Geração 2), Airflow 2	Lado a lado, transferência manual	Guia de migração manual
Airflow gerenciado (Geração 1 legada), Airflow 1	Airflow gerenciado (Geração 1 legada), Airflow 2	Lado a lado, transferência manual	Guia de migração manual

Mudanças introduzidas no Airflow 3

Antes de começar a usar ambientes do Airflow gerenciado com o Airflow 3, considere as mudanças que o Airflow 3 traz para os ambientes do Airflow gerenciado (geração 3).

Para uma visão geral das mudanças introduzidas na versão da comunidade do Airflow 3, consulte O Apache Airflow 3 está disponível para todos!.

Controle de versões do DAG

No Airflow 3, um DAG será executado até a conclusão com base na versão no início, mesmo que uma nova versão tenha sido enviada durante a execução do DAG.
- Todas as execuções de DAG na interface do Airflow agora estão associadas à versão correspondente do DAG (a versão no momento da execução). Isso inclui a estrutura de tarefas e o código DAG.

Melhorias no preenchimento

O Airflow 3 introduz uma grande revisão na forma como os preenchimentos (execução repetida de pipelines para dados históricos) são processados. Os backfills estão passando de um processo manual para um recurso totalmente observável integrado ao mecanismo principal do Airflow:

Agora, os backfills são gerenciados diretamente no programador do Airflow, em vez de serem tratados como processos manuais separados. Isso leva a uma melhor escalonabilidade e um controle mais preciso.
Agora é possível acionar, interromper e monitorar o progresso do backfill diretamente pela interface do Airflow ou por chamadas de API, além da CLI do Airflow.
O agendador do Airflow oferece melhor visibilidade do status e da integridade das execuções de preenchimento histórico.
Embora sejam muito solicitadas pela comunidade de machine learning (para retreinar modelos com dados antigos), as melhorias de backfill se aplicam a todos os fluxos de trabalho de ETL/ELT.

Segurança e confiabilidade aprimoradas

No Airflow 3, as tarefas se comunicam apenas com o servidor de API central pelo SDK de tarefas. No Airflow 2, as tarefas podiam ter acesso direto ao banco de dados. O servidor de API agrupa essas conexões de maneira eficiente. Seu banco de dados fica protegido contra picos de conexão, o que torna todo o ambiente mais estável sob cargas pesadas.
Ao usar uma nova interface de execução de tarefas, o Airflow 3 oferece melhor isolamento entre tarefas, impedindo que uma tarefa interfira ou acesse os dados de outra.
A CLI do Airflow 3 está deixando de usar o acesso direto ao banco de dados. Uma nova interface de linha de comando airflowctl é um pacote separado projetado especificamente para acesso remoto pela API. Em vez de acesso direto ao banco de dados, ele interage com o Airflow por APIs, o que é mais seguro.

Programação orientada a eventos e recursos de dados

Os conjuntos de dados evoluíram para recursos de dados. Com os recursos de dados, o Airflow consegue rastrear e reagir melhor aos dados criados ou atualizados por sistemas fora do Airflow.
Um novo conceito chamado Watchers foi introduzido no Airflow 3. Esses são componentes que monitoram mudanças em um recurso de dados, permitindo que o Airflow acione fluxos de trabalho no momento em que os dados chegam. Em vez de fazer pesquisas (verificando a cada minuto se um arquivo existe), um DAG agora pode ser acionado instantaneamente no momento em que uma mensagem chega a uma fila de mensagens.
O Airflow 3 apresenta uma nova sintaxe centrada em recursos usando decoradores do Python, o que torna o código mais limpo e intuitivo para os desenvolvedores.

Interface do Airflow modernizada

A interface do Airflow foi reescrita do zero usando React (front-end) e FastAPI (back-end).
A nova interface do Airflow realiza as operações por meio de uma API REST padronizada e uma API especializada para operações UI.
Ao substituir a implementação do Flask pelo FastAPI, a interface do Airflow fica muito mais responsiva.
As visualizações de grade e gráfico foram unificadas para um fluxo de trabalho mais tranquilo, facilitando a alternância entre estruturas de DAG de alto nível e registros de tarefas específicos.

Mudanças importantes no Airflow 3

O Airflow 3 introduz algumas mudanças importantes, sendo que algumas estão causando falhas:

Os DAGs atuais do Airflow 2 não têm garantia de funcionar com o Airflow 3. Eles precisam ser testados e possivelmente ajustados mudando importações, parâmetros de DAG e outros detalhes de implementação.
Algumas opções de configuração do Airflow 2 foram renomeadas ou removidas no Airflow 3. Consulte a Referência de configuração do Airflow para mais informações sobre parâmetros.
Não há acesso direto ao banco de dados do Airflow no código da tarefa:
- O código da tarefa não pode mais importar e usar diretamente sessões ou modelos do banco de dados do Airflow.
- Não é possível usar PostgresHook e PostgresOperator com a conexão airflow_db.
Alguns pacotes PyPI personalizados podem ser incompatíveis com a nova versão do Airflow e as dependências dele.
A API REST (/api/v1) foi substituída por /api/v2.
Os SubDAGs são substituídos por TaskGroups, Assets e Data Aware Scheduling.
Os SLAs foram descontinuados e removidos. Eles foram substituídos pelos Alertas de prazo.
O argumento "subdir" nos comandos da CLI foi removido.
Algumas variáveis de contexto do Airflow foram removidas. Para mais informações, consulte Mudanças significativas na documentação do Airflow.
O parâmetro catchup_by_default do DAG agora é False por padrão.
A configuração create_cron_data_intervals agora é False por padrão. Isso significa que o CronTriggerTimetable será usado por padrão em vez do CronDataIntervalTimetable.
Lista de mudanças do Airflow 3.0.0.
Lista de mudanças do Airflow 3.1.0.

Diferenças entre ambientes com o Airflow 3 e o Airflow 2

As principais diferenças entre os ambientes do Airflow Gerenciado com o Airflow 2 e os ambientes com o Airflow 3 são:

Configuração de cargas de trabalho em ambientes do Airflow 3:
- A quantidade mínima de memória para todos os componentes do Airflow é de 2 GB.
- As configurações para acionadores e workers do Airflow em predefinições de ambiente são diferentes dos ambientes do Airflow 2.
- O número padrão de CPUs para acionadores é 1.
- O número padrão de memória para acionadores é 2 GB.
O cálculo automático da opção de configuração [celery]worker_concurrency foi alterado para acomodar diferentes usos da memória pelos componentes do Airflow 3.
No Airflow 3, não é possível acessar diretamente o banco de dados do Airflow no código da tarefa.
O Airflow 3 usa o utilitário de linha de comando airflowctl para executar comandos da CLI do Airflow.
Os pacotes PyPI pré-instalados são diferentes nos ambientes do Airflow 3. Para conferir uma lista de pacotes PyPI pré-instalados, consulte Registro de alterações de pacotes pré-instalados.

Migrar para o Airflow 3 lado a lado

O processo de migração lado a lado tem as seguintes etapas:

Confira a compatibilidade com o Airflow 3.
Crie um ambiente do Airflow 3 e transfira as substituições de configuração e variáveis de ambiente.
Instale pacotes PyPI no ambiente do Airflow 3.
Transfira variáveis, conexões e pools para o Airflow 3.
Transfira outros dados do bucket do ambiente do Airflow 2.*.
Transfira usuários e funções.
Verifique se os DAGs estão prontos para o Airflow 3.
Transfira os DAGs para o ambiente do Airflow 3.
Monitore o ambiente do Airflow 3.

Etapa 1: verificar a compatibilidade com o Airflow 3

Para verificar a compatibilidade com o Airflow 3:

Verifique se o ambiente usa o Airflow versão 2.7 ou mais recente. Recomendamos que você faça upgrade para a versão mais recente do Airflow 2 primeiro e só depois migre para o Airflow 3.
Verifique se o ambiente está íntegro e sendo executado sem problemas há algum tempo.
Verifique se os DAGs e a configuração do Airflow não usam recursos ou funcionalidades que foram removidas no Airflow 3.
Leia as instruções para mudar seus DAGs para que sejam compatíveis com o Airflow 3 e saiba se será necessário fazer alguma mudança nos seus DAGs durante o processo de migração.
Verifique a compatibilidade dos DAGs do Airflow usando a ferramenta ruff fornecida pela versão da comunidade do Airflow. Para instruções, consulte Verificar a compatibilidade dos DAGs do Airflow na documentação do Airflow.

Etapa 2: criar um ambiente do Airflow 3, transferir substituições de configuração e variáveis de ambiente

Nesta etapa, você cria um ambiente do Airflow gerenciado (geração 3) com o Airflow 3 e começa a transferir os parâmetros de configuração do ambiente do Airflow 2:

Siga as etapas para criar um ambiente do Airflow gerenciado (geração 3) e faça o seguinte:

Ao selecionar um build do Airflow, escolha um com o Airflow 3.
Copie todas as substituições de opções de configuração do Airflow compatíveis do ambiente do Airflow 2.

Importante: algumas opções de configuração usam um nome e uma seção diferentes no Airflow 3. Nesta página, você encontra uma lista não exaustiva dessas opções.
Copie todas as variáveis de ambiente do ambiente do Airflow 2.
Crie um ambiente com o Airflow 3.

A tabela a seguir lista algumas mudanças nas opções de configuração do Airflow. Essa lista não está completa. Para mais informações sobre mudanças nas opções de configuração do Airflow, consulte a Referência de configuração do Airflow e as Notas da versão do Airflow na documentação do Airflow.

Opção do Airflow 2	Opção do Airflow 3
`[scheduler]min_file_process_interval`	`[dag_processor]min_file_process_interval`
`[webserver]rbac_user_registration_role`	`[api]rbac_user_registration_role`
`[core]dag_file_processor_timeout`	`[dag_processor]dag_file_processor_timeout`
`[scheduler]dag_dir_list_interval`	`[dag_processor]refresh_interval`
`[scheduler]max_threads`	`[dag_processor]parsing_processes`
`[scheduler]parsing_processes`	`[dag_processor]parsing_processes`
`[webserver]instance_name`	`[api]instance_name`
`[scheduler]scheduler_zombie_task_threshold`	`[scheduler]task_instance_heartbeat_timeout`
`[webserver]rbac`	Descontinuado
`[api]auth_backend=airflow.api.auth.backend.deny_all`	Descontinuado
`[api]auth_backends=airflow.api.auth.backend.deny_all`	Descontinuado
`[api]composer_auth_user_registration_role`	Descontinuado

Etapa 3: instalar pacotes PyPI no ambiente do Airflow 3

Depois que o ambiente do Airflow 3 for criado, instale pacotes PyPI nele:

Copie os requisitos do pacote PyPI do ambiente do Airflow 2.
Inicie a operação de atualização de pacotes do PyPI e aguarde a atualização do ambiente.

Como os ambientes do Airflow 3 usam um conjunto diferente de pacotes pré-instalados, talvez ocorram conflitos de pacote PyPI durante a operação de atualização. Para mais informações sobre como resolver conflitos de pacotes PyPI, consulte Conflitos com pacotes PyPI pré-instalados.

Etapa 4: exportar variáveis, conexões e pools do Airflow 2

Se você não tiver variáveis ou conexões, ignore os comandos de exportação e importação.

Se você tiver pools personalizados diferentes de default_pool, basta transferi-los. Caso contrário, ignore os comandos que exportam e importam pools.

Exporte variáveis do ambiente do Airflow 2:
```
gcloud composer environments run AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    variables -- export /home/airflow/gcs/data/variables.json
```
Substitua:
- AIRFLOW_2_ENV: o nome do ambiente do Airflow 2.
- AIRFLOW_2_LOCATION: a região em que o ambiente do Airflow 2 está localizado.
Exporte conexões do ambiente do Airflow 2:
```
gcloud composer environments run AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    connections -- export /home/airflow/gcs/data/connections.json
```
Substitua:
- AIRFLOW_2_ENV: o nome do ambiente do Airflow 2.
- AIRFLOW_2_LOCATION: a região em que o ambiente do Airflow 2 está localizado.
Exporte pools do ambiente do Airflow 2:
```
gcloud composer environments run AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    pools -- export /home/airflow/gcs/data/pools.json
```
Substitua:
- AIRFLOW_2_ENV: o nome do ambiente do Airflow 2.
- AIRFLOW_2_LOCATION: a região em que o ambiente do Airflow 2 está localizado.
Confira o nome do bucket do ambiente do Airflow 2:
```
gcloud composer environments describe AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    --format="value(storageConfig.bucket)"
```
Substitua:
- AIRFLOW_2_ENV: o nome do ambiente do Airflow 2.
- AIRFLOW_2_LOCATION: a região em que o ambiente do Airflow 2 está localizado.
Faça o download dos arquivos variables.json, connections.json e pools.json do diretório /data do bucket do seu ambiente do Airflow 2 para um diretório local:
```
gcloud storage cp gs://AIRFLOW_2_BUCKET/data/variables.json ./variables.json
gcloud storage cp gs://AIRFLOW_2_BUCKET/data/connections.json ./connections.json
gcloud storage cp gs://AIRFLOW_2_BUCKET/data/pools.json ./pools.json
```
Substitua:
- AIRFLOW_2_BUCKET: o nome do bucket do ambiente do Airflow 2, obtido na etapa anterior.

Etapa 5: importar variáveis, conexões e pools para o Airflow 3

Se você não tiver variáveis ou conexões, ignore os comandos de exportação e importação.

Se você tiver pools personalizados diferentes de default_pool, basta transferi-los. Caso contrário, ignore os comandos que exportam e importam pools.

Configure airflowctl para executar comandos da CLI do Airflow no ambiente do Airflow 3.

Importe variáveis, conexões e pools para o ambiente do Airflow 3 usando airflowctl:

airflowctl variables import ./variables.json
airflowctl connections import ./connections.json
airflowctl pools import ./pools.json

Confirme se as variáveis, conexões e pools foram importados para o ambiente do Airflow 3:
```
airflowctl variables list
airflowctl connections list
airflowctl pools list
```

Limpe os arquivos JSON:

gcloud storage rm gs://AIRFLOW_2_BUCKET/data/variables.json
gcloud storage rm gs://AIRFLOW_2_BUCKET/data/connections.json
gcloud storage rm gs://AIRFLOW_2_BUCKET/data/pools.json
rm ./variables.json
rm ./connections.json
rm ./pools.json

Substitua:

AIRFLOW_2_BUCKET: nome do bucket do ambiente do Airflow 2.

Etapa 6: transferir outros dados do bucket do ambiente do Airflow 2

Nesta etapa, você transfere os dados restantes do bucket do ambiente do Airflow 2.

Confira o nome do bucket do ambiente do Airflow 3:
```
gcloud composer environments describe AIRFLOW_3_ENV \
    --location AIRFLOW_3_LOCATION \
    --format="value(storageConfig.bucket)"
```
Substitua:
- AIRFLOW_3_ENV: o nome do ambiente do Airflow 3.
- AIRFLOW_3_LOCATION: a região em que o ambiente do Airflow 3 está localizado.
Exporte plug-ins do bucket do ambiente do Airflow 2 para o diretório /plugins no bucket do ambiente do Airflow 3:
```
gcloud composer environments storage plugins export \
  --destination=AIRFLOW_3_BUCKET/plugins \
  --environment=AIRFLOW_2_ENV \
  --location=AIRFLOW_2_LOCATION
```
Substitua:
- AIRFLOW_3_BUCKET: o nome do bucket do ambiente do Airflow 3, obtido na etapa anterior.
- AIRFLOW_2_ENV: o nome do ambiente do Airflow 2.
- AIRFLOW_2_LOCATION: a região em que o ambiente do Airflow 2 está localizado.
Verifique se o diretório /plugins foi importado com sucesso:
```
gcloud composer environments storage plugins list \
  --environment=AIRFLOW_3_ENV \
  --location=AIRFLOW_3_LOCATION
```
Substitua:
- AIRFLOW_3_ENV: o nome do ambiente do Airflow 3.
- AIRFLOW_3_LOCATION: a região em que o ambiente do Airflow 3 está localizado.
Exporte o diretório /data do ambiente do Airflow 2 para o ambiente do Airflow 3:
```
gcloud composer environments storage data export \
  --destination=AIRFLOW_3_BUCKET/data \
  --environment=AIRFLOW_2_ENV \
  --location=AIRFLOW_2_LOCATION
```
Substitua:
- AIRFLOW_3_BUCKET: o nome do bucket do ambiente do Airflow 3, obtido na etapa anterior.
- AIRFLOW_2_ENV: o nome do ambiente do Airflow 2.
- AIRFLOW_2_LOCATION: a região em que o ambiente do Airflow 2 está localizado.
Verifique se a pasta /data foi importada com sucesso:
```
gcloud composer environments storage data list \
  --environment=AIRFLOW_3_ENV \
  --location=AIRFLOW_3_LOCATION
```
Observação: se você tiver plug-ins que usam visualizações do Flask-AppBuilder (appbuilder_views), itens de menu do Flask-AppBuilder (appbuilder_menu_items) ou blueprints do Flask (flask_blueprints), considere converter para apps do FastAPI. Se você não converter, eles ainda vão funcionar no Airflow 3 porque o provedor FAB vem pré-instalado no Airflow Gerenciado e tem uma camada de compatibilidade com versões anteriores para o Airflow 3. No entanto, ainda recomendamos converter seus plug-ins para a interface de plug-in do Airflow 3: visualizações externas (external_views), apps Fast API (fastapi_apps) e middlewares do FastAPI (fastapi_root_middlewares).

Etapa 7: transferir usuários e funções

Não é possível migrar usuários e funções porque o airflowctl ainda não oferece suporte aos comandos users e roles.

Etapa 8: verificar se os DAGs estão prontos para o Airflow 3

Ajuste seus DAGs do Airflow para torná-los compatíveis com o Airflow 3.
Analise as tarefas escritas personalizadas para acesso direto ao banco de dados do Airflow:

No Airflow 3, os operadores não podem acessar o banco de dados de metadados do Airflow diretamente usando sessões de banco de dados. Se você tiver operadores personalizados, revise seu código para garantir que não haja chamadas diretas de acesso ao banco de dados.

É possível usar uma das abordagens alternativas para migrar do acesso direto ao banco de dados do Airflow nas tarefas:
- Acesse o banco de dados do Airflow exportando o conteúdo para uma instância do Cloud SQL.
- Use o cliente Python do Airflow. O cliente Python fornecido pela versão da comunidade do Airflow tem APIs definidas para a maioria das tabelas, como DagRuns, TaskInstances, Variables, Connections, XComs. O pacote apache-airflow-client já está pré-instalado nos builds do Airflow 3 do Airflow Gerenciado.
- Execute airflowctl por BashOperator de um DAG.
Se consultar o banco de dados exportado do Airflow não for uma opção para seu caso de uso e o cliente Python do Airflow e o airflowctl não oferecerem a funcionalidade necessária, peça novos endpoints de API ou recursos do SDK de tarefas na versão da comunidade do Airflow.

Observação: a solução alternativa de usar DbApiHook descrita na documentação do Airflow não pode ser usada para acessar o banco de dados do Airflow no Airflow Gerenciado porque os workers do Airflow (tarefas) não podem se comunicar com o banco de dados do Airflow.
Se você tiver tarefas KubernetesExecutor, ajuste as definições de operador substituindo queue="kubernetes" por executor="KubernetesExecutor".

Exemplo de uma tarefa KubernetesExecutor no Airflow 3:
```
PythonOperator(
task_id="airflow3_kubernetes_executor_task",
dag=dag,
python_callable=f,
executor="KubernetesExecutor",
)
```
Se você usa a variável de ambiente AIRFLOW__WEBSERVER__BASE_URL no código de tarefas, substitua-a pela opção de configuração [api]base_url do Airflow.

Exemplo de como obter esse valor no Airflow 3:
```
from airflow.configuration import conf

webserver_base_url = conf.get("api", "base_url")
```

Etapa 9: transferir DAGs para o ambiente do Airflow 3

Os seguintes problemas podem acontecer quando você transfere DAGs entre ambientes:

Se um DAG estiver ativado (não pausado) nos dois ambientes, cada ambiente executará uma cópia própria do DAG, conforme programado. Isso pode gerar execuções simultâneas de DAGs para os mesmos dados e tempo de execução.
Devido à atualização do DAG, o Airflow programa execuções extras de DAGs, começando pela data de início especificada nos DAGs. Isso acontece porque a nova instância do Airflow não considera o histórico de execuções do DAG no ambiente do Airflow 2. Isso pode levar a um grande número de execuções de DAGs programadas a partir da data de início especificada.

Impedir execuções simultâneas de DAGs

No ambiente do Airflow 3, substitua a opção de configuração dags_are_paused_at_creation do Airflow. Depois que você fizer essa alteração, todos os novos DAGs serão pausados por padrão.

Seção	Chave	Valor
`core`	`dags_are_paused_at_creation`	`True`

Evitar execuções extras ou ausentes de DAGs

Especifique uma nova data de início estática nos DAGs que você transferiu para o ambiente do Airflow 3.

Para evitar lacunas e sobreposições nas datas lógicas, a primeira execução do DAG precisa acontecer no ambiente do Airflow 3 na próxima ocorrência do intervalo de programação. Para fazer isso, defina a nova data de início no DAG como anterior à data da última execução no ambiente do Airflow 2.

Por exemplo, se o DAG for executado às 15h, 17h e 21h todos os dias no ambiente do Airflow 2, a última execução do DAG aconteceu às 15h e você pretende transferir o DAG às 15h15, a data de início do ambiente do Airflow 3 pode ser hoje às 14h45. Depois de ativar o DAG no ambiente do Airflow 3, ele programará uma execução do DAG para às 17h.

Outro exemplo: se o DAG for executado à 00h todos os dias no ambiente do Airflow 2, a última execução do DAG aconteceu às 00h de 26 de março de 2026 e você planeja transferir o DAG às 13h de 26 de março de 2026, a data de início do ambiente do Airflow 3 pode ser às 23h45 de 25 de março de 2026. Depois de ativar o DAG no ambiente do Airflow 3, ele programará uma execução do DAG para 00h do dia 27 de março de 2026.

Transferir os DAGs um por um para o ambiente do Airflow 3

Siga este procedimento para transferir cada DAG:

Verifique se a nova data de início no DAG está configurada conforme descrito na seção anterior.
Faça upload do DAG atualizado para o ambiente do Airflow 3. Esse DAG está pausado no ambiente do Airflow 3 devido à substituição da configuração. Portanto, nenhuma execução de DAG ainda está programada.
Na interface da Web do Airflow, acesse DAGs e verifique se há erros de sintaxe de DAG relatados.
No momento em que você planeja transferir o DAG:
1. Pause o DAG no ambiente do Airflow 2.
2. Cancele a pausa do DAG no ambiente do Airflow 3.
3. Verifique se a nova execução do DAG está programada para o horário correto.
4. Aguarde a execução do DAG acontecer no ambiente do Airflow 3 e verifique se foi bem-sucedida.
Se a execução do DAG for bem-sucedida:
- Se a execução do DAG for bem-sucedida, será possível continuar e usar o DAG no ambiente do Airflow 3. Por fim, considere excluir a versão do Airflow 2 do DAG.
- Se a execução do DAG falhar, tente resolver problemas do DAG até que ele seja executado com sucesso no Airflow 3.
  
  Se necessário, sempre é possível recorrer à versão do Airflow 2 do DAG:
  1. Pause o DAG no ambiente do Airflow 3.
  2. Cancele a pausa do DAG no ambiente do Airflow 3. Assim você programa uma nova execução do DAG para a mesma data e hora que a execução do DAG com falha.
  3. Quando tudo estiver pronto para continuar com a versão do Airflow 3 do DAG, ajuste a data de início, faça upload da nova versão do DAG para o ambiente do Airflow 3 e repita o procedimento.

Etapa 10: monitorar o ambiente do Airflow 3

Depois de transferir todos os DAGs e a configuração para o ambiente do Airflow 3, monitore-os em busca de possíveis problemas, execuções com falha do DAG e integridade geral do ambiente. Se o ambiente do Airflow 3 for executado sem problemas por um período suficiente, será possível remover o ambiente do Airflow 2.