https://drift-tracker.toolforge.org/report/core/ shows a schema drift for:
Mismatching field type of text.old_flags
on s3, s7
The field is a tinyblob since addition 64ac6b8e775dd8582ea9cc5f24235488f076c5b3
But wmf production is using varbinary on some sections:
root@db1112.eqiad.wmnet[thwikiquote]> show create table text\G
*************************** 1. row ***************************
Table: text
Create Table: CREATE TABLE `text` (
`old_id` int(8) unsigned NOT NULL AUTO_INCREMENT,
`old_text` mediumblob NOT NULL,
`old_flags` varbinary(255) NOT NULL,
PRIMARY KEY (`old_id`)
) ENGINE=InnoDB AUTO_INCREMENT=42791 DEFAULT CHARSET=binary PACK_KEYS=1
1 row in set (0.001 sec)Maybe the varbinary(255) is a better datatype from the production view?
A new task is should be used to request a code change and later adjust the other sections for the newest schema with this task
There is no ready ALTER statement in the commit history.
ALTER TABLE /*_*/text CHANGE old_flags old_flags TINYBLOB NOT NULL;
- ALTERs to run: see above
- Where to run those changes: s3, s7 - list of wikis needs to be created
- When to run those changes: any time
- If the schema change is backwards compatible: Yes
- If the schema change has been tested already on some of the test/beta wikis: beta cluster is running with the new schema
- if the data should be made available on the labs replicas and/or dumps: no change of the existing rules
Progress
- s1 (not needed)
- s2 (not needed)
- s3
- s4 (not needed)
- s5
- s6
- s7
- s8 (not needed)