Risoluzione dei problemi dello scheduler Airflow

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

Questa pagina fornisce procedure e informazioni per la risoluzione dei problemi problemi con gli 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 ulteriori informazioni 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 scheduler, potrebbero non analizzare tutti i DAG. Questo potrebbe comportare molti problemi che presenti 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 del DAG per i DAG che non è stato possibile analizzare potrebbero essere contrassegnati 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:

  • 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:

  1. Nella console Google Cloud, vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nell'elenco degli ambienti, fai clic sul nome dell'ambiente. Si apre la pagina Monitoring.

  3. Nella scheda Monitoring, esamina il tempo di analisi totale per tutti i DAG file nella sezione Esecuzioni DAG e identificano i possibili problemi.

    La sezione Esecuzioni di DAG nella scheda Monitoraggio di Composer mostra le metriche di integrità per i DAG nel tuo ambiente

Controlla i tempi di analisi dei DAG con la scheda Log di Cloud Composer:

  1. Nella console Google Cloud, vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nell'elenco degli ambienti, fai clic sul nome dell'ambiente. Si apre la pagina Monitoring.

  3. Vai alla scheda Log e all'albero di navigazione Tutti i log. seleziona la sezione Gestore processore DAG.

  4. Esamina i log di dag-processor-manager e identifica i possibili problemi.

    I log del processore DAG mostreranno i tempi di analisi del DAG

gcloud - Airflow 1

Usa il comando list_dags con il flag -r per visualizzare l'ora di analisi per tutti i tuoi 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 può indicare uno dei tuoi 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 tuoi DAG non è implementato in modo ottimale. Dalla tabella di output, puoi identificare quali DAG molto tempo di analisi.

Monitoraggio delle attività in esecuzione e in coda

Per verificare se ci sono attività bloccate in una coda, procedi nel seguente modo.

  1. Nella console Google Cloud, vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nell'elenco degli ambienti, fai clic sul nome dell'ambiente. Si apre la pagina Dettagli ambiente.

  3. Vai alla scheda Monitoring.

  4. Nella scheda Monitoring, esamina il grafico delle attività di Airflow nella sezione Esecuzioni DAG e identificare i possibili problemi. Attività Airflow sono attività in stato in coda in Airflow, possono andare Coda del broker Celery o Kubernetes Executor. Le attività in coda Celery sono attività 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 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 riscontra problemi di prestazioni relativi all'analisi e alla pianificazione dei DAG, valuta che esegue la migrazione ad Airflow 2.

In Cloud Composer 1, lo scheduler viene eseguito sui nodi cluster insieme ad altri componenti Cloud Composer. Per questo motivo, il carico di singole di nodi cluster potrebbero essere più alti o più bassi rispetto ad altri nodi. Lo scheduler delle prestazioni (analisi e pianificazione dei DAG) potrebbero variare a seconda del nodo in cui viene eseguito lo scheduler. Inoltre, un singolo nodo in cui le esecuzioni dello scheduler possono cambiare in seguito a operazioni di upgrade o manutenzione. Questa limitazione è stata risolta in Cloud Composer 2, dove puoi allocare Le risorse di CPU e memoria per lo scheduler e le prestazioni dello scheduler non dipendono dal carico dei nodi del cluster.

Numero limitato di thread

Consentendo al gestore del processore DAG (la parte dello scheduler che elabora i file DAG) per utilizzare solo un numero limitato di thread potrebbero influire il 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, sostituisci il 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, sostituisci il 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 gran numero di attività di machine learning. In questi casi, ti consigliamo di scegliere un numero inferiore consolidate.

Anche la pianificazione di un numero elevato di DAG o attività contemporaneamente può essere una delle possibili fonti di problemi. 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 con le 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, scopri di più 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 un una nuova funzionalità chiamata 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 il 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 prestazioni migliori ed eseguire la migrazione dei DAG al suo interno.
  • Crea più ambienti Cloud Composer e suddividi i DAG tra di 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.
  • Esegui l'upgrade del tipo di macchina dell'istanza Cloud SQL che esegue Airflow database nel tuo ambiente, ad esempio utilizzando Comandi gcloud composer environments update. Le scarse prestazioni 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 completamente gestito di Google Cloud. Durante questi periodi di tempo, gli 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 Airflow saltando i dati non necessari dei file nella cartella dei DAG. Lo scheduler Airflow ignora file e cartelle specificato nel file .airflowignore.

Per fare in modo che lo scheduler Airflow ignori i file non necessari:

  1. Crea un file .airflowignore.
  2. In questo file, elenca i file e le cartelle da ignorare.
  3. Carica questo file nella cartella /dags dell'archivio del bucket dell'ambiente.

Per ulteriori informazioni sul formato file .airflowignore, vedi 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 si risparmiano worker Airflow di elaborazione dei cicli di elaborazione.

Lo scheduler Airflow continuerà ad analizzare i DAG in pausa. Se vuoi davvero migliora le prestazioni dello scheduler Airflow, usa .airflowignore o elimina in pausa i DAG dalla cartella dei DAG.

Utilizzo di "wait_for_downstream" nei tuoi DAG

Se imposti il parametro wait_for_downstream su True nei DAG, affinché un'attività abbia esito positivo, tutte le attività immediatamente downstream anche l'attività deve riuscire. Significa che l'esecuzione di attività appartenenti a determinate esecuzioni dei DAG potrebbero essere rallentate dall'esecuzione di attività dalla precedente Esecuzione di DAG. Scopri di più in la documentazione di Airflow.

Le attività in coda troppo a lungo verranno annullate e riprogrammate

Se un'attività Airflow viene tenuta in coda troppo a lungo, lo scheduler lo riprogramma per l'esecuzione (nelle versioni Airflow precedenti alla 2.3.1, l'attività viene contrassegnata come non riuscita e viene tentata di nuovo se idonea per un nuovo tentativo).

Un modo per osservare i sintomi di questa situazione è osservare il grafico con il numero di attività in coda Scheda ("Monitoring" nella UI di Cloud Composer) e se i picchi in questo grafico non calano entro circa due ore, molto probabilmente le attività verranno riprogrammate (senza log) seguite "Le attività approvate erano ancora in attesa ..." e le voci di log nei log dello scheduler. In questi casi, potrebbe essere visualizzato il messaggio "File di log non trovato..." messaggio nei log delle attività di Airflow perché l'attività non è stata eseguita.

In generale, questo comportamento è previsto e la successiva istanza del modello deve essere eseguita in base alla pianificazione. Se noti molti nei tuoi ambienti Cloud Composer, allora potrebbe significare che non ci sia abbastanza worker Airflow nel tuo ambiente per elaborare tutti le attività pianificate.

Risoluzione: per risolvere il problema, devi assicurarti che ci sia sempre capacità nei worker di Airflow per eseguire attività in coda. Ad esempio, puoi aumentare il numero worker o worker_concurrency. Puoi anche ottimizzare il parallelismo o i pool evita di accodare le attività oltre la 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 le situazioni in cui sono presenti attività inattive in coda e, per qualche motivo, possibile eseguirle correttamente (ad es. un DAG a cui appartengono le attività inattive è stata eliminata).

Se queste attività inattive non vengono eliminate definitivamente dallo scheduler, potresti dover manualmente. Puoi farlo, ad esempio, nella UI di Airflow. Puoi vai a (Menu &gt; Browser &gt;) istanze di attività), trova le attività in coda appartenenti a un DAG inattivo ed eliminale.

Per risolvere il problema, esegui l'upgrade del tuo ambiente a Cloud Composer versione 2.1.12 o 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 utilizzi 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 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 tutti i DAG sono pianificati e il parametro [scheduler]num_runs controlla quante volte viene eseguito dallo scheduler. Quando scheduler raggiunge [scheduler]num_runs loop di pianificazione, reboot. Lo scheduler è un componente stateless e il riavvio un meccanismo di riparazione automatica per gli eventuali problemi riscontrati dallo scheduler. Se non specificato, il valore predefinito valore di [scheduler]num_runs che è 5000.

    Puoi utilizzare [scheduler]min_file_process_interval per configurare la frequenza L'analisi del DAG avviene, ma questo parametro non può durare più del tempo richiesto affinché uno scheduler esegua [scheduler]num_runs vengono eseguiti loop durante la pianificazione dei DAG.

Scalabilità della configurazione di Airflow

Airflow offre opzioni di configurazione che controllano quante attività I DAG Airflow possono essere eseguiti contemporaneamente. Per impostare queste opzioni di configurazione, sostituire i propri valori per il tuo ambiente.

  • Contemporaneità dei worker

    Il parametro [celery]worker_concurrency controlla il numero massimo di delle attività che un worker di Airflow può eseguire contemporaneamente. Se moltiplichiamo il valore di questo parametro per il numero di worker Airflow in dell'ambiente Cloud Composer, il numero massimo che possono essere eseguite in un determinato momento nel tuo ambiente. Questo è limitato dall'opzione di configurazione Airflow [core]parallelism, che viene descritto in dettaglio.

    Negli ambienti Cloud Composer 2, il valore predefinito Il valore [celery]worker_concurrency viene calcolato automaticamente

    • Per le versioni Airflow 2.3.3 e successive, è impostato [celery]worker_concurrency a 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 worker CPU.

  • Numero massimo di esecuzioni DAG attive

    L'opzione di configurazione Airflow [core]max_active_runs_per_dag controlla l'opzione il numero massimo di esecuzioni di DAG attive per DAG. Lo scheduler non crea altre esecuzioni di DAG se raggiunge questo limite.

    Se questo parametro è impostato in modo errato, potrebbe verificarsi un problema lo scheduler limita l'esecuzione dei DAG perché non può creare altri DAG di eseguire le istanze in un dato momento.

  • Numero massimo di attività attive per DAG

    L'opzione di configurazione Airflow [core]max_active_tasks_per_dag controlla numero massimo di istanze di attività che possono essere eseguite contemporaneamente in ogni 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é c'è solo un numero limitato di attività DAG che possono essere eseguite 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 il numero di attività che lo scheduler Airflow può mettere in coda nella coda dell'esecutore dopo tutto 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. Cloud Composer e utilizzano un solo pool. La dimensione di questo pool controlla il numero possono essere messe in coda dallo scheduler per l'esecuzione in un determinato momento. Se la dimensione del pool è troppo piccola, lo scheduler non può inserire in coda le attività esecuzione nonostante le soglie, che sono definite Opzione di configurazione [core]parallelism e per l'opzione di configurazione [celery]worker_concurrency moltiplicata per di worker Airflow, non sono ancora soddisfatti.

    Puoi configurare le dimensioni del pool nella UI di Airflow (Menu > Admin > Piscine). Regola le dimensioni del pool in base al livello di parallelismo previsto del tuo ambiente.

    Di solito, [core]parallelism è impostato un 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à che non sono state completate (in esecuzione, pianificate e in coda) come non riuscita se un'esecuzione del DAG non viene completata entro dagrun_timeout (un parametro DAG).

Soluzione:

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 essere sintomo del fatto che il database Airflow sia sovraccaricato dal numero di connessioni aperte o di query eseguiti nello stesso tempo, da scheduler o da altri componenti Airflow come worker, triggerer e server web.

Possibili soluzioni:

Sul server web viene visualizzato il messaggio "Lo scheduler non sembra essere in esecuzione" avviso

Lo scheduler segnala regolarmente il proprio battito cardiaco ad Airflow per configurare un database. In base a queste informazioni, il server web di Airflow determina se scheduler è attivo.

A volte, se lo scheduler è sottoposto a un carico elevato, potrebbe non essere in grado segnala il suo battito 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 e consumano troppe risorse dello scheduler.

  • Evita di utilizzare variabili globali nei DAG Airflow: Variabili di ambiente di Cloud Composer e Variabili Airflow.

  • Aumenta il valore del parametro [scheduler]scheduler-health-check-threshold in modo che il server web attenda più tempo prima di segnalare l'indisponibilità dei lo 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 il metodo --rerun_failed_tasks argomento.

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 il metodo --rerun-failed-tasks argomento.

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 DAG start_date, in nel formato YYYY-MM-DD.
  • END_DATE con un valore per il parametro DAG end_date, in nel formato YYYY-MM-DD.
  • DAG_NAME con il nome del DAG.

L'operazione di backfill a volte può generare una situazione di deadlock in cui il backfill non è possibile perché un'attività è bloccata. 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:

Passaggi successivi