sqlalchemy.exc.OperationalError during dag-processor #30443
Replies: 4 comments 4 replies
-
You need to see why your server keeps on closing the connection. This looks like instability of your mysql server. It could have been caused by some misconfiguration of your serve, but only your sever logs can tell it. Please take a look there. Converting into a discussion - maybe looking at your server logs will shed some more light. |
Beta Was this translation helpful? Give feedback.
-
well here are the logs that we see when this happens
please note we are using mysql with AWS serverless aurora, and here is what I found in their docs about this error based on this we've tried to set the parameter This fix was deployed today, and so far it seems to have resolved our issue. I will monitor it going forward and comment here if we see more failures. If you have any other ideas on what to do please let us know :) |
Beta Was this translation helpful? Give feedback.
-
I can confirm that after 1 hour the same error remains, with the same logs |
Beta Was this translation helpful? Give feedback.
-
So the following parameter change seems to have calmed things down... + parameter {
+ apply_method = "immediate"
+ name = "interactive_timeout"
+ value = "60000"
}
+ parameter {
+ apply_method = "immediate"
+ name = "max_allowed_packet"
+ value = "1073741824"
}
+ parameter {
+ apply_method = "immediate"
+ name = "net_read_timeout"
+ value = "60000"
}
+ parameter {
+ apply_method = "immediate"
+ name = "net_write_timeout"
+ value = "60000"
}
+ parameter {
+ apply_method = "immediate"
+ name = "wait_timeout"
+ value = "60000"
} but I've basically set them to their maximum value. I feel like something is unstable in terms of how airflow is handling connections when using the dag-processor |
Beta Was this translation helpful? Give feedback.
-
Apache Airflow version
2.5.3
What happened
While our
dag-processor
it keeps coming across this errorWhat you think should happen instead
dag-processor should complete without an error
How to reproduce
Run airflow pod with dag-processor, wait 10 minutes
We run our airflow based on the https://github.com/airflow-helm/charts chart, we've forked one of their deployments like this:
Operating System
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"
Versions of Apache Airflow Providers
apache-airflow-providers-amazon==7.1.0
apache-airflow-providers-celery==3.1.0
apache-airflow-providers-cncf-kubernetes==5.1.1
apache-airflow-providers-common-sql==1.3.3
apache-airflow-providers-docker==3.4.0
apache-airflow-providers-elasticsearch==4.3.3
apache-airflow-providers-ftp==3.3.0
apache-airflow-providers-google==8.8.0
apache-airflow-providers-grpc==3.1.0
apache-airflow-providers-hashicorp==3.2.0
apache-airflow-providers-http==4.1.1
apache-airflow-providers-imap==3.1.1
apache-airflow-providers-microsoft-azure==5.1.0
apache-airflow-providers-mysql==4.0.0
apache-airflow-providers-odbc==3.2.1
apache-airflow-providers-postgres==5.4.0
apache-airflow-providers-redis==3.1.0
apache-airflow-providers-sendgrid==3.1.0
apache-airflow-providers-sftp==4.2.1
apache-airflow-providers-slack==7.2.0
apache-airflow-providers-sqlite==3.3.1
apache-airflow-providers-ssh==3.4.0
Deployment
Other 3rd-party Helm chart
Deployment details
No response
Anything else
No response
Are you willing to submit PR?
Code of Conduct
Beta Was this translation helpful? Give feedback.
All reactions