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),
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)
NOTE: VARCHAR(255) fields with utf8mb4 charset have a size of up to 1020 bytes. That exceed the 767 bytes limit for an index. The easy workaround is to limit the size of the key/index to 191 VARCHAR (764 bytes).
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.
| | 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