This is merely a support request. I am migrating MediaWiki CI jobs to a Debian Stretch container and a lot of them are failing when creating tables:
CREATE TABLE `abuse_filter_action` ( afa_filter BIGINT unsigned NOT NULL, afa_consequence varchar(255) NOT NULL, /* <----- */ afa_parameters TINYBLOB NOT NULL, PRIMARY KEY (afa_filter,afa_consequence), KEY (afa_consequence) ) ENGINE=InnoDB Function: Wikimedia\Rdbms\Database::sourceFile( /workspace/src/extensions/AbuseFilter/abusefilter.tables.sql ) Error: 1071 Specified key was too long; max key length is 767 bytes (localhost:/tmp/quibble-mysql-abvt891k/socket)
I had the issue with a fake test schema in mediawiki/core which I solved by lowering the varchar to 127 https://gerrit.wikimedia.org/r/#/c/419858/ . Given the schema is never used for a deployment, that is an acceptable fix/workaround. But for a schema meant to be deployed we can't just change the varchar size.
From the previous commit the explanation I came up with is:
MediaWikiTestCaseSchemaTest.sql comes with two varchar(255) combined into a PRIMARY KEY.
That caused the testsuite to fail creating that imagelinks table with:Error: 1071 Specified key was too long; max key length is 767 bytes
That is the limit for innodb and when using UTF8 it allows up to 3 bytes per characters. Hence the key can be (255+255)*3 = 1530. One can tune MySQL to bump the limit to ~ 3k with: innodb_large_prefix = 1
The mystery is the same works fine on Nodepool disposable instances. So I must be missing a configuration tweak of some sort.
Environment
| Nodepool | Docker | |
| Distro | Jessie | Stretch |
| MariaDB | 10.0.32-0+deb8u1 | MariaDB 10.1.26-0+deb9u1 |
| character-set-server | latin1 | utf8mb4 |
| collation-server | latin1_swedish_ci | utf8mb4_general_ci |
| --help --verbose | F17337439 | F17337441 |
docker-registry.wikimedia.org/releng/quibble-stretch:0.0.11