[
https://issues.apache.org/jira/browse/AIRFLOW-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16726178#comment-16726178
]
Gerardo commented on AIRFLOW-3445:
----------------------------------
This has become a major problem for our team. We followed the patch suggested
above; however, we've observed some strange behavior when triggering a DagRun
from the interface:
Logs:
WARNING - Set 1 task instances to state=None as their associated Dag Run is not
in running state
(https://github.com/apache/incubator-airflow/blob/master/airflow/jobs.py#L1023)
It will repeat this warning ad infinitum until the dag is canceled. Looking at
the task instances table in our MariaDB reveals that new task instances are
filling up the table, each with utc now() for the time.
According to the above file
(https://github.com/apache/incubator-airflow/blob/master/airflow/jobs.py#L1023),
if a task instance cannot successfully be joined onto a dag run with the same
ID and execute_date, it will set its status to None, thereby canceling our
DagRun.
It's unclear to me why the first TaskInstance would have a different
execute_date than our dag run, but clearly it must. I have a strong suspicion
that the Task Instance is being created in the database with a NULL
execute_date, which MariaDB will fill with the current timestamp. See:
execution_date=sa.text('CURRENT_TIMESTAMP(6)') in Roger/Feng Lu's patch.
What else could be going wrong here?
> MariaDB explicit_defaults_for_timestamp = 1 Does not work.
> ----------------------------------------------------------
>
> Key: AIRFLOW-3445
> URL: https://issues.apache.org/jira/browse/AIRFLOW-3445
> Project: Apache Airflow
> Issue Type: Bug
> Components: database
> Affects Versions: 1.10.1
> Environment: Hosted VM on the Google Cloud Platform, Compute Engine:
> Machine type: n1-standard-2 (2 vCPUs, 7.5 GB memory)
> Operating System CentOS
> Reporter: Conor Molloy
> Priority: Blocker
> Fix For: 1.10.2
>
>
> {{Running into an issue when running }}
> {{`airflow upgradedb`}}
> {{ going from `1.9` -> `1.10.1`}}
> {{}}
> {code:java}
> `sqlalchemy.exc.OperationalError: (_mysql_exceptions.OperationalError) (1193,
> "Unknown system variable 'explicit_defaults_for_timestamp'") [SQL: 'SELECT
> @@explicit_defaults_for_timestamp']`{code}
> {{I saw this link on the airflow website.}}
> {{[https://airflow.readthedocs.io/en/stable/faq.html#how-to-fix-exception-global-variable-explicit-defaults-for-timestamp-needs-to-be-on-1|http://example.com]}}
> {{Here it says you can set}}
> {code:java}
> `explicit_defaults_for_timestamp = 1`{code}
> {{in the _my.cnf_ file. However I am using Mariadb and when I add this to the
> _my.cnf_ file the}}
> {noformat}
> mariadb.service{noformat}
> {{fails to start up. Has anyone else come across this issue?}}
>
> The output from
> {code:java}
> `SHOW VARIABLES like '%version%'`{code}
> was
> {code:java}
> `+-------------------------+----------------------+`
> `| Variable_name | Value |`
> `+-------------------------+----------------------+`
> `| innodb_version | 5.5.59-MariaDB-38.11 |`
> `| protocol_version | 10 |`
> `| slave_type_conversions | |`
> `| version | 5.5.60-MariaDB |`
> `| version_comment | MariaDB Server |`
> `| version_compile_machine | x86_64 |`
> `| version_compile_os | Linux |`
> `+-------------------------+----------------------+`{code}
> The MariaDB does not have the argument as it is a MySQL only feature.
> [https://mariadb.com/kb/en/library/system-variable-differences-between-mariadb-100-and-mysql-56/|http://example.com]
> There may need to be a check for MariaDB before upgrading, as mentioned by
> Ash in this Slack thread.
> [https://apache-airflow.slack.com/archives/CCQB40SQJ/p1543918149008100|http://example.com]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
