Page MenuHomePhabricator

Update cx-notification-log table in Production
Closed, ResolvedPublic

Description

  • The ALTER TABLES to run: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/628843/10/sql/patch-2020-09-21-notification-log-add-wikiid.sql
  • Where to run those changes: extension1, DB: wikishared (Production)
  • When to run those changes: Along with EU Backport Window (After Week of 21st June is OK)
  • If the schema change is backwards compatible: Backward compatibility added.
  • If the schema change has been tested already on some of the test/beta wikis. Usually, as a last test, change should be applied to testwiki first: Tested on cloud instances, testwiki requires deployment separately.
  • If it involves new columns or tables, if the data should be made available on the labs replicas. Similar question if it involves deletion of data previously available on labs: Not needed.

Progress

  • s3 (testwiki)
  • x1 (wikishared)

Event Timeline

@KartikMistry the task says this needs to be done the week of 21st of June, which is already gone (as the DBAs were tagged the 27th, we had no visibility about this before that).
Does this schema change need to happen during a release or can it happen anytime from now on?

@KartikMistry the task says this needs to be done the week of 21st of June, which is already gone (as the DBAs were tagged the 27th, we had no visibility about this before that).
Does this schema change need to happen during a release or can it happen anytime from now on?

We were waiting for patch to get deployed everywhere. So, it can be done anytime now. Note that testwiki database for ContentTranslation is different than in other Wikis (testwiki instead of default wikishared database).

Let me know when it can be done.

Also, I thought only Schema-change tag is sufficient :)

So this needs to go to extension1 + testwiki (s3) right?.
As you mentioned on irc, you'd like this to be applied to testwikifirst, right?
We have the DC switchover this week, so we are not doing any schema changes or any other maintenance till it is done. We'll resume all those around next week, but we have a long queue of things, so I don't expect this to be shipped to testwiki next week either, sorry.

Schema-change doesn't notify it. Normally once you are ready for your schema change to be done in production either DBA and/or Schema-change-in-production need to be applied: https://wikitech.wikimedia.org/wiki/Schema_changes#Workflow_of_a_schema_change

Self note: x1 runs RBR, so this needs to be executed directly on the primary master with replication enabled.

@KartikMistry as we discussed via IRC a few days ago, I have added the column and the index in testwiki:

root@db2105.codfw.wmnet[testwiki]> show create table cx_notification_log;
+---------------------+----------------------------------------------------------------------------------------------------------------
| Table               | Create Table
+---------------------+----------------------------------------------------------------------------------------------------------------
| cx_notification_log | CREATE TABLE `cx_notification_log` (
  `cxn_id` int(11) NOT NULL AUTO_INCREMENT,
  `cxn_date` varbinary(14) NOT NULL,
  `cxn_newest` varbinary(14) NOT NULL,
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  PRIMARY KEY (`cxn_id`),
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
) ENGINE=InnoDB DEFAULT CHARSET=binary |
+---------------------+----------------------------------------------------------------------------------------------------------------
1 row in set (0.032 sec)
dbstore1007.eqiad.wmnet:3313
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
dbstore1004.eqiad.wmnet:3313
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db2149.codfw.wmnet:3306
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db2139.codfw.wmnet:3313
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db2127.codfw.wmnet:3306
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db2109.codfw.wmnet:3306
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db2105.codfw.wmnet:3306
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db2094.codfw.wmnet:3313
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db2074.codfw.wmnet:3306
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db1179.eqiad.wmnet:3306
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db1175.eqiad.wmnet:3306
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db1166.eqiad.wmnet:3306
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db1157.eqiad.wmnet:3306
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db1154.eqiad.wmnet:3313
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db1123.eqiad.wmnet:3306
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db1112.eqiad.wmnet:3306
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
db1102.eqiad.wmnet:3313
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
clouddb1021.eqiad.wmnet:3313
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
clouddb1017.eqiad.wmnet:3313
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
clouddb1013.eqiad.wmnet:3313
  `cxn_wiki_id` varbinary(64) DEFAULT NULL,
  KEY `cxn_wiki_id_newest` (`cxn_wiki_id`,`cxn_newest`)
Marostegui moved this task from Backlog to In progress on the Schema-change-in-production board.
Marostegui moved this task from Ready to In progress on the DBA board.
Marostegui updated the task description. (Show Details)

This is all done