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.