[
https://issues.apache.org/jira/browse/AIRFLOW-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757506#comment-16757506
]
Thayne McCombs commented on AIRFLOW-3786:
-----------------------------------------
> assuming you're using utf8mb4 encoding, correct?
correct.
As a workaround, we have changed the default character encoding to "utf8" for
the airflow database. Which is probably fine since we probably won't need to
use any unicode code points that require four bytes in utf8 in our airflow
data. Probably.
I would suggest two changes:
1. Make the ID_LEN configurable, if possible.
2. Add documentation to the Database setup page explaining that if the utf8mb4
encoding is used then either the ID_LEN needs to be shorter (assuming 1 is
done) or the innodb_large_prefix option needs to be enabled.
> mysql initdb failes because the primary key is too large.
> ----------------------------------------------------------
>
> Key: AIRFLOW-3786
> URL: https://issues.apache.org/jira/browse/AIRFLOW-3786
> Project: Apache Airflow
> Issue Type: Bug
> Components: database
> Affects Versions: 1.10.2
> Reporter: Thayne McCombs
> Priority: Major
>
> When running `airflow initdb` using a mysql server using the utf8mb character
> set, I get this error:
> ```
> sqlalchemy.exc.OperationalError: (MySQLdb._exceptions.OperationalError)
> (1071, 'Specified key was too long; max key length is 767 bytes') [SQL:
> '\nCREATE TABLE dag (\n\tdag_id VARCHAR(250) NOT NULL, \n\tis_paused BOOL,
> \n\tis_subdag BOOL, \n\tis_active BOOL, \n\tlast_scheduler_run DATETIME,
> \n\tlast_pickled DATETIME, \n\tlast_expired DATETIME, \n\tscheduler_lock
> BOOL, \n\tpickle_id INTEGER, \n\tfileloc VARCHAR(2000), \n\towners
> VARCHAR(2000), \n\tPRIMARY KEY (dag_id), \n\tCHECK (is_paused IN (0, 1)),
> \n\tCHECK (is_subdag IN (0, 1)), \n\tCHECK (is_active IN (0, 1)), \n\tCHECK
> (scheduler_lock IN (0, 1))\n)\n\n'] (Background on this error at:
> [http://sqlalche.me/e/e3q8)]
> ```
> I've found a few stack overflow questions from other users that have run into
> this problem, the workarounds given are to either enable innodb_large_prefix,
> (which I can't do) or use utf8 or ascii encoding for the database (not
> desirable). Ideally, this should just work, or at the very least, have well
> documented workarounds for this problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
