Page MenuHomePhabricator

Deploy dropping wb_entity_per_page table
Closed, ResolvedPublic

Description

We want the table to be dropped (after the patch got deployed, meaning wmf-3).

  • The table only exists in wikibase repos (wikidatawiki (s5), testwikidatawiki (s3)) and we need to drop these, no change to other wikis is needed
  • I have the patch that if gets merged, it will fix the beta and then we can see if it works just fine or not.
  • It's not b/c compatible, we can't restore dropped table (I think at least) but the table won't be used in the production anyway. The replicas in labs need to drop it too.

Event Timeline

Ladsgroup created this task.Oct 6 2017, 1:06 PM

Change 382693 had a related patch set uploaded (by Ladsgroup; owner: Amir Sarabadani):
[mediawiki/extensions/Wikibase@master] Drop wb_entity_per_page table if it exists

https://gerrit.wikimedia.org/r/382693

Change 382693 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Drop wb_entity_per_page table if it exists

https://gerrit.wikimedia.org/r/382693

Hi @Ladsgroup - I am a bit confused with this ticket.
Is this something you will do? Or something the DBAs have to do (and hence the Blocked-on-schema-change )?

This is something for the DBAs, this patch only does it for the beta cluster, I was thinking do you need .sql file or you can directly do "DROP TABLE foo" too?

Marostegui moved this task from Triage to Backlog on the DBA board.Oct 6 2017, 6:15 PM

This is something for the DBAs, this patch only does it for the beta cluster, I was thinking do you need .sql file or you can directly do "DROP TABLE foo" too?

We don't strictly need it no.
So as this is merged, is this ok to be started then, right?

It's merged but not deployed, we should wait for a week if train doesn't get stuck (more if it does)

It's merged but not deployed, we should wait for a week if train doesn't get stuck (more if it does)

Sounds good - can you ping us once we are good to proceed?

Sure. Thanks!

jcrespo moved this task from Backlog to Blocked external/Not db team on the DBA board.
jcrespo added a subscriber: jcrespo.

Add Blocked-on-schema-change, that way we will know it is ready :-)

@Ladsgroup just to be clear, it needs to be dropped everywhere except from wikidatawiki (s5) and testwikidatawiki (s3)?

@Marostegui : No, it's the other way around. It needs to be dropped in these two wikis only because it's a repo database and the table doesn't exist in client wikis.

@Marostegui : No, it's the other way around. It needs to be dropped in these two wikis only because it's a repo database and the table doesn't exist in client wikis.

Then the original task description is a bit confusing:

We want the table to be dropped (after the patch got deployed, meaning wmf-3).

It's only needed on wikibase repos (wikidatawiki (s5), testwikidatawiki (s3))

By "It" I meant the dropping, I'm sorry for the confusion, will update the task description.

Ladsgroup updated the task description. (Show Details)Oct 17 2017, 11:27 AM

By "It" I meant the dropping, I'm sorry for the confusion, will update the task description.

Clear now! Sorry for making you re-write it, but better be safe than sorry :)

Does this need to be backuped or can it just be dropped?
Ideally I will rename it on a production slave and leave it like that for a few days before killing it.

hoo added a comment.Oct 20 2017, 8:48 AM

Does this need to be backuped or can it just be dropped?
Ideally I will rename it on a production slave and leave it like that for a few days before killing it.

If we really wanted/ needed to, we could easily re-generate the data from the page table… but that's not going to be needed.

A backup would be great, all crazy things can happen. One thing that would be great to know is to see if it's being read / written at all, I know it can be tricky and if it's too much hassle, let's move forward with back up in hand just in case.

@hoo, you are right but re-generating it might take some time.

A backup would be great, all crazy things can happen. One thing that would be great to know is to see if it's being read / written at all, I know it can be tricky and if it's too much hassle, let's move forward with back up in hand just in case.

That is the idea behind the rename.
If it is being written, replication will break. If it is being read, we should see some errors on logtash.
Backups have been taken and left at:

root@dbstore1001:/srv/tmp/T177601# pwd
/srv/tmp/T177601
root@dbstore1001:/srv/tmp/T177601# ls -lh
total 1.2G
-rw-r--r-- 1 root root 3.2M Oct 20 08:53 s3_wb_entity_per_page.sql
-rw-r--r-- 1 root root 1.2G Oct 20 08:53 s5_wb_entity_per_page.sql
Marostegui moved this task from Next to In progress on the DBA board.

Mentioned in SAL (#wikimedia-operations) [2017-10-23T08:09:17Z] <marostegui> Rename wb_entity_per_page table on s5 db1092 and s3 db1077 - T177601

I have renamed this table on the following servers

s5: wikidatawiki: db1092

root@db1092[wikidatawiki]> set session sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)

root@db1092[wikidatawiki]> rename table wb_entity_per_page to T177601_wb_entity_per_page;
Query OK, 0 rows affected (0.01 sec)

To revert this change, connect to db1092 and execute:

use wikidatawiki;
set session sql_log_bin=0;
rename table T177601_wb_entity_per_page to wb_entity_per_page;

s3: testwikidatawiki: db1077

root@db1077[testwikidatawiki]> set session sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)

root@db1077[testwikidatawiki]> rename table wb_entity_per_page to T177601_wb_entity_per_page;
Query OK, 0 rows affected (0.00 sec)

To revert this change, connect to db1077 and execute:

use testwikidatawiki;
set session sql_log_bin=0;
rename table T177601_wb_entity_per_page to wb_entity_per_page;

There have been no errors so I will be dropping this table on Monday (because I do not want to drop stuff on a Friday :-) )

Mentioned in SAL (#wikimedia-operations) [2017-10-30T09:08:42Z] <marostegui> Drop wb_entity_per_page page from s3 and s5 - T177601

Marostegui closed this task as Resolved.Oct 30 2017, 9:10 AM

Table has been dropped everywhere