Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
Questa pagina fornisce i passaggi per la risoluzione dei problemi e le informazioni per i problemi comuni degli scheduler di Airflow.
Identificare l'origine del problema
Per iniziare la risoluzione dei problemi, identifica se il problema si verifica al momento dell'analisi del DAG o durante l'elaborazione delle attività al momento dell'esecuzione. Per saperne di più sul tempo di analisi e di esecuzione, consulta Differenza tra tempo di analisi dei DAG e tempo di esecuzione del DAG.
Ispezione dei log del processore DAG
Se hai DAG complessi, il processore DAG, eseguito dallo scheduler, potrebbe non analizzare tutti i tuoi DAG. Ciò può causare molti problemi con i seguenti sintomi.
Sintomi:
Se il processore DAG riscontra problemi durante l'analisi dei DAG, potrebbe causare una combinazione dei problemi elencati di seguito. Se i DAG vengono generati in modo dinamico, questi problemi potrebbero avere un impatto maggiore rispetto ai DAG statici.
I DAG non sono visibili nella UI di Airflow e DAG.
L'esecuzione dei DAG non è pianificata.
Nei log del processore DAG sono presenti errori, ad esempio:
dag-processor-manager [2023-04-21 21:10:44,510] {manager.py:1144} ERROR - Processor for /home/airflow/gcs/dags/dag-example.py with PID 68311 started at 2023-04-21T21:09:53.772793+00:00 has timed out, killing it.
o
dag-processor-manager [2023-04-26 06:18:34,860] {manager.py:948} ERROR - Processor for /home/airflow/gcs/dags/dag-example.py exited with return code 1.
Gli scheduler di Airflow riscontrano problemi che comportano il riavvio dello scheduler.
Le attività Airflow pianificate per l'esecuzione vengono annullate e le esecuzioni dei DAG per i DAG che non è stato possibile analizzare potrebbero essere contrassegnate come
failed
. Ad esempio:airflow-scheduler Failed to get task '<TaskInstance: dag-example.task1--1 manual__2023-04-17T10:02:03.137439+00:00 [removed]>' for dag 'dag-example'. Marking it as removed.
Soluzione:
Aumenta i parametri relativi all'analisi dei DAG:
Aumenta dagbag-import-timeout ad almeno 120 secondi (o più, se necessario).
Aumenta dag-file-processor-timeout ad almeno 180 secondi (o più, se necessario). Questo valore deve essere superiore a
dagbag-import-timeout
.
Correggi o rimuovi i DAG che causano problemi al processore DAG.
Ispezione dei tempi di analisi dei DAG
Per verificare se il problema si verifica al momento dell'analisi del DAG, segui questi passaggi.
Console
Nella console Google Cloud puoi utilizzare la pagina Monitoring e la scheda Log per esaminare i tempi di analisi dei DAG.
Controlla i tempi di analisi dei DAG con la pagina Monitoraggio di Cloud Composer:
Nella console Google Cloud, vai alla pagina Ambienti.
Nell'elenco degli ambienti, fai clic sul nome dell'ambiente. Si apre la pagina Monitoring.
Nella scheda Monitoring, esamina il grafico Tempo di analisi totale per tutti i file DAG nella sezione Esecuzioni DAG e identifica i possibili problemi.
Controlla i tempi di analisi dei DAG con la scheda Log di Cloud Composer:
Nella console Google Cloud, vai alla pagina Ambienti.
Nell'elenco degli ambienti, fai clic sul nome dell'ambiente. Si apre la pagina Monitoring.
Vai alla scheda Log e seleziona la sezione Gestore processori DAG dall'albero di navigazione Tutti i log.
Esamina i log di
dag-processor-manager
e identifica i possibili problemi.
gcloud - Airflow 1
Utilizza il comando list_dags
con il flag -r
per visualizzare il tempo di analisi
per tutti i DAG.
gcloud composer environments run ENVIRONMENT_NAME \
--location LOCATION \
list_dags -- -r
Sostituisci:
ENVIRONMENT_NAME
con il nome dell'ambiente.LOCATION
con la regione in cui si trova l'ambiente.
L'output del comando è simile al seguente:
-------------------------------------------------------------------
DagBag loading stats for /home/airflow/gcs/dags
-------------------------------------------------------------------
Number of DAGs: 5
Total task number: 13
DagBag parsing time: 0.6765180000000001
-----------+----------+---------+----------+-----------------------
file | duration | dag_num | task_num | dags
-----------+----------+---------+----------+-----------------------
/dag_1.py | 0.6477 | 1 | 2 | ['dag_1']
/dag_2.py | 0.018652 | 1 | 2 | ['dag_2']
/dag_3.py | 0.004024 | 1 | 6 | ['dag_3']
/dag_4.py | 0.003476 | 1 | 2 | ['dag_4']
/dag_5.py | 0.002666 | 1 | 1 | ['dag_5']
-----------+----------+---------+----------+-----------------------
Cerca il valore del Tempo di analisi DagBag. Un valore elevato potrebbe indicare che uno dei DAG non è implementato in modo ottimale. Dalla tabella di output, puoi identificare quali DAG hanno un tempo di analisi lungo.
gcloud - Airflow 2
Utilizza il comando dags report
per vedere il tempo di analisi per tutti i DAG.
gcloud composer environments run ENVIRONMENT_NAME \
--location LOCATION \
dags report
Sostituisci:
ENVIRONMENT_NAME
con il nome dell'ambiente.LOCATION
con la regione in cui si trova l'ambiente.
L'output del comando è simile al seguente:
Executing within the following Kubernetes cluster namespace: composer-2-0-31-airflow-2-3-3
file | duration | dag_num | task_num | dags
======================+================+=========+==========+===================
/manydagsbig.py | 0:00:00.038334 | 2 | 10 | serial-0,serial-0
/airflow_monitoring.py| 0:00:00.001620 | 1 | 1 | airflow_monitoring
Cerca il valore di duration per ciascuno dei rinforzi elencati nella tabella. Un valore elevato potrebbe indicare che uno dei DAG non è implementato in modo ottimale. Dalla tabella di output, puoi identificare i DAG che hanno un tempo di analisi lungo.
Monitoraggio delle attività in esecuzione e in coda
Per verificare se ci sono attività bloccate in una coda, procedi nel seguente modo.
Nella console Google Cloud, vai alla pagina Ambienti.
Nell'elenco degli ambienti, fai clic sul nome dell'ambiente. Si apre la pagina Dettagli ambiente.
Vai alla scheda Monitoring.
Nella scheda Monitoring, esamina il grafico delle attività Airflow nella sezione Esecuzioni DAG e identifica i possibili problemi. Le attività Airflow sono in stato in coda in Airflow e possono andare alla coda del broker Celery o Kubernetes Executor. Le attività in coda Celery sono istanze di attività che vengono inserite nella coda del broker Celery.
Risoluzione dei problemi al momento di analisi del DAG
Le seguenti sezioni descrivono i sintomi e le potenziali correzioni per alcuni problemi comuni al momento dell'analisi dei DAG.
Analisi e pianificazione dei DAG in Cloud Composer 1 e Airflow 1
L'efficienza dell'analisi dei DAG è stata notevolmente migliorata in Airflow 2. Se riscontri problemi di prestazioni relativi all'analisi e alla pianificazione dei DAG, valuta la possibilità di eseguire la migrazione ad Airflow 2.
In Cloud Composer 1, lo scheduler viene eseguito sui nodi cluster insieme ad altri componenti di Cloud Composer. Per questo motivo, il carico dei singoli nodi del cluster potrebbe essere superiore o inferiore rispetto ad altri nodi. Le prestazioni dello scheduler (analisi e pianificazione dei DAG) possono variare a seconda del nodo su cui viene eseguito lo scheduler. Inoltre, un singolo nodo in cui viene eseguito lo scheduler può cambiare in seguito a operazioni di upgrade o manutenzione. Questo limite è stato risolto in Cloud Composer 2, dove è possibile allocare risorse di CPU e memoria allo scheduler e le sue prestazioni non dipendono dal carico dei nodi del cluster.
Numero limitato di thread
Consentire al gestore del processore DAG (la parte dello scheduler che elabora i file DAG) di utilizzare solo un numero limitato di thread potrebbe influire sul tempo di analisi dei DAG.
Per risolvere il problema, esegui l'override delle seguenti opzioni di configurazione di Airflow:
Per Airflow 1.10.12 e versioni precedenti, esegui l'override del parametro
max_threads
:Sezione Chiave Valore Note scheduler
max_threads
NUMBER_OF_CORES_IN_MACHINE - 1
Sostituisci NUMBER_OF_CORES_IN_MACHINE
con il numero di core
nelle macchine dei nodi worker.Per Airflow 1.10.14 e versioni successive, esegui l'override del parametro
parsing_processes
:Sezione Chiave Valore Note scheduler
parsing_processes
NUMBER_OF_CORES_IN_MACHINE - 1
Sostituisci NUMBER_OF_CORES_IN_MACHINE
con il numero di core
nelle macchine dei nodi worker.
Distribuzione di numero e tempo delle attività
Airflow è noto per avere problemi con la pianificazione di un numero elevato di attività di piccole dimensioni. In questi casi, ti consigliamo di scegliere un numero inferiore di attività più consolidate.
Una possibile causa di problemi potrebbe essere la pianificazione di un numero elevato di DAG o attività contemporaneamente. Per evitare questo problema, distribuisci le attività in modo più uniforme nel tempo.
Risoluzione dei problemi relativi alle attività in esecuzione e in coda
Le seguenti sezioni descrivono i sintomi e le potenziali correzioni per alcuni problemi comuni relativi alle attività in esecuzione e in coda.
Le code di attività sono troppo lunghe
In alcuni casi, una coda di attività potrebbe essere troppo lunga per lo scheduler. Per informazioni su come ottimizzare i parametri worker e Celery, leggi come scalare l'ambiente Cloud Composer insieme alla tua azienda.
Utilizzo della funzionalità TimeTable dello scheduler di Airflow
A partire da Airflow 2.2, puoi definire una tabella temporale per un DAG utilizzando una nuova funzionalità denominata TimeTable.
Puoi definire una tabella temporale utilizzando uno dei seguenti metodi:
Risorse cluster limitate
Questa sezione riguarda solo Cloud Composer 1.
Potresti riscontrare problemi di prestazioni se il cluster GKE del tuo ambiente è troppo piccolo per gestire tutti i DAG e le attività. In questo caso, prova una delle seguenti soluzioni:
- Crea un nuovo ambiente con un tipo di macchina che offre maggiori prestazioni e migra i tuoi DAG al suo interno.
- Creare altri ambienti Cloud Composer e suddividere i DAG tra loro.
- Cambia il tipo di macchina per i nodi GKE, come descritto in Upgrade del tipo di macchina per i nodi GKE. Poiché questa procedura è soggetta a errori, è l'opzione meno consigliata.
- Eseguire l'upgrade del tipo di macchina dell'istanza Cloud SQL che esegue il database Airflow nel tuo ambiente, ad esempio utilizzando i comandi
gcloud composer environments update
. Le prestazioni ridotte del database Airflow potrebbero essere il motivo per cui lo scheduler è lento.
Evita la pianificazione delle attività durante i periodi di manutenzione
Puoi definire periodi di manutenzione specifici per il tuo ambiente. Durante questi periodi di tempo si verificano eventi di manutenzione per Cloud SQL e GKE.
Fai in modo che lo scheduler Airflow ignori i file non necessari
Puoi migliorare le prestazioni dello scheduler di Airflow saltando i file non necessari nella cartella dei DAG. Lo scheduler Airflow ignora i file e le cartelle
specificati nel file .airflowignore
.
Per fare in modo che lo scheduler Airflow ignori i file non necessari:
- Crea un file
.airflowignore
. - In questo file, elenca i file e le cartelle da ignorare.
- Carica questo file nella cartella
/dags
del bucket del tuo ambiente.
Per saperne di più sul formato file .airflowignore
, consulta la documentazione di Airflow.
Lo scheduler Airflow elabora i DAG in pausa
Gli utenti di Airflow mettono in pausa i DAG per evitarne l'esecuzione. In questo modo vengono salvati i cicli di elaborazione dei worker di Airflow.
Lo scheduler Airflow continuerà ad analizzare i DAG in pausa. Se vuoi davvero migliorare le prestazioni dello scheduler Airflow, utilizza .airflowignore
o elimina i DAG in pausa dalla cartella dei DAG.
Utilizzo di "wait_for_downstream" nei DAG
Se imposti il parametro wait_for_downstream
su True
nei DAG, affinché un'attività vada a buon fine, anche tutte le attività immediatamente downstream
di questa attività devono riuscire. Significa che l'esecuzione delle attività appartenenti a una determinata esecuzione del DAG potrebbe essere rallentata dall'esecuzione delle attività della precedente esecuzione del DAG. Scopri di più nella documentazione di Airflow.
Le attività in coda troppo a lungo verranno annullate e riprogrammate
Se un'attività Airflow rimane in coda troppo a lungo, lo scheduler la riprogramma di nuovo per l'esecuzione (nelle versioni di Airflow precedenti alla 2.3.1, l'attività viene anche contrassegnata come non riuscita e riprova se idonea per un nuovo tentativo).
Un modo per osservare i sintomi di questa situazione è esaminare il grafico con il numero di attività in coda (scheda "Monitoraggio" nella UI di Cloud Composer) e se i picchi in questo grafico non scendono entro circa due ore, è molto probabile che le attività vengano riprogrammate (senza log) seguite dalle voci di log "Le attività adottate erano ancora in sospeso ..." nei log dello scheduler. In questi casi, potresti visualizzare il messaggio "Il file di log non è stato trovato..." nei log delle attività di Airflow perché l'attività non è stata eseguita.
In generale, questo comportamento è previsto e l'istanza successiva dell'attività pianificata deve essere eseguita in base alla pianificazione. Se osservi molti di questi casi nei tuoi ambienti Cloud Composer, potrebbe significare che nel tuo ambiente non ci sono abbastanza worker Airflow per elaborare tutte le attività pianificate.
Soluzione: per risolvere il problema, devi assicurarti che i worker di Airflow abbiano sempre la capacità di eseguire attività in coda. Ad esempio, puoi aumentare il numero di worker o worker_concurrency. Puoi anche ottimizzare il parallelismo o i pool per evitare le attività di accodamento superiori alla capacità a tua disposizione.
Sporadicamente, attività inattive potrebbero bloccare l'esecuzione di un DAG specifico
Nei casi normali, lo scheduler Airflow dovrebbe essere in grado di gestire situazioni in cui sono presenti attività inattive in coda e per qualche motivo non è possibile eseguirle correttamente (ad esempio, un DAG a cui appartengono le attività inattive è stato eliminato).
Se queste attività inattive non vengono eliminate definitivamente dallo scheduler, potresti doverle eliminare manualmente. Puoi farlo, ad esempio, nella UI di Airflow: puoi accedere a (Menu > Browser > Istanze di attività), trovare le attività in coda appartenenti a un DAG inattivo ed eliminarle.
Per risolvere il problema, esegui l'upgrade dell'ambiente a Cloud Composer 2.1.12 o versioni successive.
Approccio di Cloud Composer al parametro [scheduler]min_file_process_interval
Cloud Composer cambia il modo in cui [scheduler]min_file_process_interval
viene utilizzato dallo scheduler di Airflow.
Flusso d'aria 1
Nel caso di Cloud Composer che utilizza Airflow 1, gli utenti possono impostare il valore di [scheduler]min_file_process_interval
tra 0 e 600 secondi. Valori superiori a 600 secondi generano gli stessi risultati dell'impostazione di [scheduler]min_file_process_interval
su 600 secondi.
Flusso d'aria 2
In Airflow 2, [scheduler]min_file_process_interval
può essere utilizzato solo con
le versioni 1.19.9 e 2.0.26 o più recenti
Versioni di Cloud Composer precedenti a 1.19.9 e 2.0.26
In queste versioni,
[scheduler]min_file_process_interval
viene ignorato.Cloud Composer 1.19.9 o 2.0.26 o versioni più recenti
Lo scheduler Airflow viene riavviato dopo un certo numero di volte in cui tutti i DAG sono stati pianificati e il parametro
[scheduler]num_runs
controlla quante volte viene eseguito dallo scheduler. Quando lo scheduler raggiunge[scheduler]num_runs
loop di pianificazione, viene riavviato. Lo scheduler è un componente stateless e questo riavvio è un meccanismo di riparazione automatica per eventuali problemi che lo scheduler potrebbe riscontrare. Se non specificato, viene applicato il valore predefinito di[scheduler]num_runs
, che è 5000.[scheduler]min_file_process_interval
può essere utilizzato per configurare la frequenza dell'analisi dei DAG, ma questo parametro non può essere più lungo del tempo necessario affinché uno scheduler esegua i loop di[scheduler]num_runs
durante la pianificazione dei DAG.
Scalabilità della configurazione di Airflow
Airflow offre opzioni di configurazione di Airflow che controllano quante attività e quanti DAG possono eseguire contemporaneamente. Per impostare queste opzioni di configurazione, sostituisci i relativi valori per il tuo ambiente.
-
Il parametro
[celery]worker_concurrency
controlla il numero massimo di attività che un worker Airflow può eseguire contemporaneamente. Se moltiplichi il valore di questo parametro per il numero di worker Airflow nel tuo ambiente Cloud Composer, ottieni il numero massimo di attività che possono essere eseguite in un determinato momento nel tuo ambiente. Questo numero è limitato dall'opzione di configurazione Airflow[core]parallelism
, descritta in maggior dettaglio.Negli ambienti Cloud Composer 2, il valore predefinito di
[celery]worker_concurrency
viene calcolato automaticamentePer le versioni Airflow 2.3.3 e successive,
[celery]worker_concurrency
è impostato su un valore minimo di 32, 12 * worker_CPU e 8 * worker_memory.Per le versioni Airflow 2.2.5 o precedenti,
[celery]worker_concurrency
è impostato su 12 * numero di CPU dei worker.
Numero massimo di esecuzioni DAG attive
L'opzione di configurazione Airflow
[core]max_active_runs_per_dag
controlla il numero massimo di esecuzioni di DAG attive per DAG. Lo scheduler non crea più esecuzioni di DAG se raggiunge questo limite.Se questo parametro non è impostato correttamente, potrebbe verificarsi un problema in cui lo scheduler limita l'esecuzione dei DAG perché non può creare altre istanze di esecuzione dei DAG in un determinato momento.
Numero massimo di attività attive per DAG
L'opzione di configurazione Airflow
[core]max_active_tasks_per_dag
controlla il numero massimo di istanze di attività che possono essere eseguite contemporaneamente in ciascun DAG. È un parametro a livello di DAG.Se questo parametro non è impostato correttamente, potrebbe verificarsi un problema in cui l'esecuzione di una singola istanza DAG è lenta perché esiste solo un numero limitato di attività DAG che è possibile eseguire in un determinato momento.
Soluzione: aumenta
[core]max_active_tasks_per_dag
.Parallelismo e dimensioni del pool
L'opzione di configurazione Airflow
[core]parallelism
controlla quante attività lo scheduler Airflow può mettere in coda nella coda dell'esecutore dopo aver soddisfatto tutte le dipendenze per queste attività.Si tratta di un parametro globale per l'intera configurazione di Airflow.
Le attività vengono accodate ed eseguite all'interno di un pool. Gli ambienti Cloud Composer utilizzano un solo pool. La dimensione di questo pool controlla quante attività possono essere messe in coda dallo scheduler per l'esecuzione in un determinato momento. Se le dimensioni del pool sono troppo ridotte, lo scheduler non può inserire in coda le attività per l'esecuzione anche se le soglie, definite dall'opzione di configurazione
[core]parallelism
e dall'opzione di configurazione[celery]worker_concurrency
moltiplicata per il numero di worker Airflow, non sono ancora soddisfatte.Puoi configurare le dimensioni del pool nella UI di Airflow (Menu > Amministratore > Pool). Regola le dimensioni del pool in base al livello di parallelismo previsto nel tuo ambiente.
Di solito,
[core]parallelism
è impostato come prodotto del numero massimo di worker e [celery]worker_concurrency.
I DAG non sono pianificati dallo scheduler a causa dei timeout del processore DAG
Per saperne di più su questo problema, consulta Risoluzione dei problemi dei DAG.
Attività contrassegnate come non riuscite dopo aver raggiunto dagrun_timeout
Lo scheduler contrassegna le attività non completate (in esecuzione, pianificate e in coda) come non riuscite se un'esecuzione di DAG non viene completata entro dagrun_timeout
(un parametro DAG).
Soluzione:
Estendi
dagrun_timeout
per rispettare il timeout.(Cloud Composer 2) Aumenta il numero di worker o aumenta i parametri delle prestazioni dei worker, in modo che il DAG venga eseguito più velocemente.
Sintomi della pressione di carico del database Airflow
A volte, nei log dello scheduler Airflow potresti vedere la seguente voce di log di avviso:
Scheduler heartbeat got an exception: (_mysql_exceptions.OperationalError) (2006, "Lost connection to MySQL server at 'reading initial communication packet', system error: 0")"
Sintomi simili potrebbero essere osservati anche nei log dei worker di Airflow:
Per MySQL:
(_mysql_exceptions.OperationalError) (2006, "Lost connection to MySQL server at
'reading initial communication packet', system error: 0")"
Per PostgreSQL:
psycopg2.OperationalError: connection to server at ... failed
Questi errori o avvisi potrebbero indicare che il database Airflow è sovraccaricato dal numero di connessioni aperte o dal numero di query eseguite contemporaneamente, da scheduler o da altri componenti di Airflow come worker, triggerer e server web.
Possibili soluzioni:
Fai lo scale up del database Airflow:
- (Cloud Composer 1) Cambia il tipo di macchina dell'istanza Cloud SQL che archivia il database Airflow del tuo ambiente.
- (Cloud Composer 2) Regola le dimensioni dell'ambiente.
Riduci il numero di scheduler. Nella maggior parte dei casi, uno o due scheduler sono sufficienti per analizzare e pianificare le attività Airflow. Non è consigliabile configurare più di due scheduler, a meno che non ci sia un caso giustificato.
Evita di utilizzare variabili globali nei DAG di Airflow: variabili di ambiente di Cloud Composer e variabili Airflow.
Imposta [scheduler]scheduler-heartbeat-sec su un valore più alto, ad esempio su 15 secondi o più.
Imposta [scheduler]job-heartbeat-sec su un valore più alto, ad esempio 30 secondi o più.
Imposta [scheduler]scheduler_health_check_threshold su un valore uguale a
[scheduler]job-heartbeat-sec
moltiplicato per4
.
Sul server web viene visualizzato l'avviso "Lo scheduler non sembra essere in esecuzione"
Lo scheduler segnala regolarmente il suo heartbeat al database Airflow. In base a queste informazioni, il server web di Airflow determina se lo scheduler è attivo.
A volte, se lo scheduler è sottoposto a un carico elevato, potrebbe non essere in grado di segnalare il suo battito cardiaco ogni [scheduler]scheduler-heartbeat-sec.
In una situazione di questo tipo, il server web Airflow potrebbe mostrare il seguente avviso:
The scheduler does not appear to be running. Last heartbeat was received <X>
seconds ago.
Possibili soluzioni:
Aumentare la CPU e la memoria delle risorse per lo scheduler.
Ottimizza i DAG in modo che l'analisi e la pianificazione vengano eseguite più rapidamente e non utilizzino troppo le risorse dello scheduler.
Evita di utilizzare variabili globali nei DAG di Airflow: variabili di ambiente di Cloud Composer e variabili Airflow.
Aumenta il valore di [scheduler]scheduler-health-check-threshold in modo che il server web aspetti più a lungo prima di segnalare l'indisponibilità dello scheduler.
Soluzioni per i problemi riscontrati durante il backfill dei DAG
A volte potresti voler eseguire nuovamente i DAG che sono già stati eseguiti. Puoi farlo con lo strumento a riga di comando Airflow nel seguente modo:
Flusso d'aria 1
gcloud composer environments run \
ENVIRONMENT_NAME \
--location LOCATION \
backfill -- -B \
-s START_DATE \
-e END_DATE \
DAG_NAME
Per eseguire nuovamente solo le attività non riuscite per uno specifico DAG, utilizza anche
l'argomento --rerun_failed_tasks
.
Flusso d'aria 2
gcloud composer environments run \
ENVIRONMENT_NAME \
--location LOCATION \
dags backfill -- -B \
-s START_DATE \
-e END_DATE \
DAG_NAME
Per eseguire nuovamente solo le attività non riuscite per uno specifico DAG, utilizza anche
l'argomento --rerun-failed-tasks
.
Sostituisci:
ENVIRONMENT_NAME
con il nome dell'ambiente.LOCATION
con la regione in cui si trova l'ambiente.START_DATE
con un valore per il parametro DAGstart_date
, nel formatoYYYY-MM-DD
.END_DATE
con un valore per il parametro DAGend_date
, nel formatoYYYY-MM-DD
.DAG_NAME
con il nome del DAG.
L'operazione di backfill a volte potrebbe generare una situazione di deadlock in cui non è possibile un backfill perché esiste un blocco su un'attività. Ad esempio:
2022-11-08 21:24:18.198 CET DAG ID Task ID Run ID Try number
2022-11-08 21:24:18.201 CET -------- --------- -------- ------------
2022-11-08 21:24:18.202 CET 2022-11-08 21:24:18.203 CET These tasks are deadlocked:
2022-11-08 21:24:18.203 CET DAG ID Task ID Run ID Try number
2022-11-08 21:24:18.204 CET ----------------------- ----------- ----------------------------------- ------------
2022-11-08 21:24:18.204 CET <DAG name> <Task name> backfill__2022-10-27T00:00:00+00:00 1
2022-11-08 21:24:19.249 CET Command exited with return code 1
...
2022-11-08 21:24:19.348 CET Failed to execute job 627927 for task backfill
In alcuni casi, puoi utilizzare le seguenti soluzioni alternative per superare i deadlock:
Disabilita mini-Scheduler eseguendo l'override di
[core]schedule-after-task-execution
suFalse
.Esegui backfill per intervalli di date più ristretti. Ad esempio, imposta
START_DATE
eEND_DATE
per specificare un periodo di un solo giorno.