What:
ALTER TABLE /*_*/flow_wiki_ref MODIFY ref_src_wiki varchar(64) binary not null;
Where: Everywhere that has the flow_wiki_ref table. private wikis have it as part of their database. everywhere else is extension1/flowdb
When: At DBA's leisure (patch is merged, no code dependancy)
Is backwards compatible: Yes
Has been tested already: On Miraheze per subtask. Live on beta
Schema change progress:
s3:
x1
s10
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Marostegui | T241387 Extend flow_wiki_ref.ref_src_wiki | |||
| Resolved | Paladox | T232351 Increase data limit for 'ref_src_wiki' column |
This being not an emergency, and due to deployment freeze + team vacations, I will schedule to be done in the year 2020 CC @Marostegui
List of wikis that have this table:
s1 - none
s2 - none
s3:
s4; none
s5: none
s6: none
s7: none
s8: none
x1: flowdb
s10: labswiki
@Andrew I guess if labswiki has this table, labtestwiki probably has it too.
That table isn't present on labtestwiki -- I must not have ever installed flow there.
Mentioned in SAL (#wikimedia-operations) [2020-01-02T06:46:48Z] <marostegui> Deploy schema change on db2131 - T241387
db2131 flowdb.flow_wiki_ref has been altered and this is how it looks like now:
CREATE TABLE `flow_wiki_ref` ( `ref_src_object_id` binary(11) NOT NULL, `ref_src_object_type` varbinary(32) NOT NULL, `ref_src_workflow_id` binary(11) NOT NULL, `ref_src_namespace` int(11) NOT NULL, `ref_src_title` varbinary(255) NOT NULL, `ref_target_namespace` int(11) NOT NULL, `ref_target_title` varbinary(255) NOT NULL, `ref_type` varbinary(16) NOT NULL, `ref_src_wiki` varbinary(64) NOT NULL, `ref_id` binary(11) NOT NULL, PRIMARY KEY (`ref_id`), KEY `flow_wiki_ref_idx_v2` (`ref_src_wiki`,`ref_src_namespace`,`ref_src_title`,`ref_type`,`ref_target_namespace`,`ref_target_title`,`ref_src_object_type`,`ref_src_object_id`), KEY `flow_wiki_ref_revision_v2` (`ref_src_wiki`,`ref_src_namespace`,`ref_src_title`,`ref_src_object_type`,`ref_src_object_id`,`ref_type`,`ref_target_namespace`,`ref_target_title`) ) ENGINE=InnoDB DEFAULT CHARSET=binar
Mentioned in SAL (#wikimedia-operations) [2020-01-02T07:18:37Z] <marostegui> Deploy schema change on labswiki.flow_wiki_ref (empty table) T241387
Wikitech has been altered, it was empty anyways:
root@db1133.eqiad.wmnet[labswiki]> select count(*) from flow_wiki_ref; +----------+ | count(*) | +----------+ | 0 | +----------+ 1 row in set (0.00 sec) root@db1133.eqiad.wmnet[labswiki]> ALTER TABLE /*_*/flow_wiki_ref MODIFY ref_src_wiki varchar(64) binary not null; Query OK, 0 rows affected (0.01 sec) Records: 0 Duplicates: 0 Warnings: 0
As I was expecting, as soon as we got a write to that table (it doesn't have many, so it took a while), replication broke on db2131 x1 (we use ROW):
Last_SQL_Error: Column 8 of table 'flowdb.flow_wiki_ref' cannot be converted from type 'varchar(16)' to type 'varbinary(64)'
I have reverted the change and replication is working again on that unused host.
So this needs to be done directly on the master with replication. Luckily the table doesn't have many writes and the alter is relatively fast (10 seconds). So I think I will perform this early in the morning and getting the master to serve reads.
Mentioned in SAL (#wikimedia-operations) [2020-01-02T07:49:19Z] <marostegui> Deploy schema change on techconductwiki.flow_wiki_ref (empty table) on s3 master (db1123) T241387
Mentioned in SAL (#wikimedia-operations) [2020-01-02T08:10:21Z] <marostegui> Deploy schema change on officewiki.flow_wiki_ref on s3 master (db1123) T241387
Mentioned in SAL (#wikimedia-operations) [2020-01-13T05:51:42Z] <marostegui> Deploy schema change on x1 master on flowdb with replication - T241387