[go: up one dir, main page]

Page MenuHomePhabricator

Remove pagetriage_log table
Closed, ResolvedPublic

Description

Follow-up from https://gerrit.wikimedia.org/r/c/878938 and https://gerrit.wikimedia.org/r/c/870742 from task T325519: Remove PageTriageUtil::getTopTriagers() and ApiPageTriageStats topreviewers=1

  1. Table to delete: pagetriage_log
  2. Where to run those changes: tbd
  3. When to run those changes: At any time
  4. If the schema change is backwards compatible: The code that removes reference to pagetriage_log was introduced in wmf.19
  5. If the schema change has been tested already on some of the test/beta wikis: I believe so
  6. if the data should be made available on the labs replicas and/or dumps: n/a

Progress:

  • s1 (enwiki)
  • s3 (testwiki and test2wiki)

Event Timeline

kostajh changed the task status from Open to Stalled.Jan 30 2023, 2:31 PM
kostajh updated the task description. (Show Details)
kostajh added a project: PageTriage.
kostajh added subscribers: Novem_Linguae, Tgr.

Marking as stalled so that @Novem_Linguae has a chance to review and confirm this request. Cc also @Tgr.

Marostegui moved this task from Triage to Blocked on the DBA board.

It should be only on s1 and maybe testwiki on s3?

It should be only on s1 and maybe testwiki on s3?

I am not sure. Where could I find out this information?

Novem_Linguae changed the task status from Stalled to Open.Jan 31 2023, 12:57 PM
Novem_Linguae updated the task description. (Show Details)

LGTM. I added test2wiki to the task. I think enwiki, testwiki, and test2wiki should cover all of PageTriage's deployments.

It should be only on s1 and maybe testwiki on s3?

I am not sure. Where could I find out this information?

It is only installed in English Wikipedia and test wikis. These are only s1 and s3. You can see them in https://noc.wikimedia.org/db.php or mediawiki-config repo.

It should be only on s1 and maybe testwiki on s3?

I am not sure. Where could I find out this information?

It is only installed in English Wikipedia and test wikis. These are only s1 and s3. You can see them in https://noc.wikimedia.org/db.php or mediawiki-config repo.

Ack, thanks. (Side note: @Ladsgroup it might be nice if testwiki and test2wiki were listed on https://noc.wikimedia.org/db.php in addition to the generic "Any wiki not hosted on the other sections" text, what do you think?)

honestly that whole page needs a redesign but that's a future-me problem.

Marostegui subscribed.

Removing this tag as this isn't really a schema change (we only consider ALTER as schema changes)

Removing this tag as this isn't really a schema change (we only consider ALTER as schema changes)

OK. I was going by what Krinkle had done in the previous task.

https://wikitech.wikimedia.org/wiki/Schema_changes#What_is_not_a_schema_change says:

Lower priority and normally do not block anyone, while being even more dangerous than an alter. Add them to task T54921 or as a subtask of that instead.

Is that still accurate? That task says (T54921#7092428) to add the tables to be dropped to https://wikitech.wikimedia.org/wiki/Obsolete_or_unneeded_database_tables, should I do that?

Lower priority and normally do not block anyone, while being even more dangerous than an alter. Add them to task T54921 or as a subtask of that instead.

Is that still accurate?

I changed the last part into "File them as a regular DBA team task.", it can be detailed later (e.g. your initial information was actually very useful, even if not all was clear in the beginning).

@kostajh Do they need a backup before deletion?

I changed the last part into "File them as a regular DBA team task.", it can be detailed later (e.g. your initial information was actually very useful, even if not all was clear in the beginning).

Thanks!

@kostajh Do they need a backup before deletion?

I think that would be nice to have, just in case.

I confirm I only saw the table on test2wiki and testwiki on backups, other than enwiki:

$ ls *.tar | while read f; do tar --wildcards -tvf $f '*pagetriage_log*' 2> /dev/null; done
-rw-r--r-- dump/dump       322 2023-01-31 02:42 test2wiki.pagetriage_log-schema.sql.gz
-rw-r--r-- dump/dump     10999 2023-01-31 02:28 test2wiki.pagetriage_log.sql.gz
-rw-r--r-- dump/dump       322 2023-01-31 02:42 testwiki.pagetriage_log-schema.sql.gz
-rw-r--r-- dump/dump      7836 2023-01-31 02:29 testwiki.pagetriage_log.sql.gz

I've left the dump at dbprov1001:/srv/backups/dumps/latest/dump.pagetriage_log.2023-02-03--10-38-00 for bacula to back it up, deletion can proceed.

@kostajh It is important to note backups' guarantee is a recovery for approximately the next 3 months- but it is not a long archival method. After that, they will be rotated and purged (backups are not a long term archival solution!).

Removing this tag as this isn't really a schema change (we only consider ALTER as schema changes)

OK. I was going by what Krinkle had done in the previous task.

https://wikitech.wikimedia.org/wiki/Schema_changes#What_is_not_a_schema_change says:

Lower priority and normally do not block anyone, while being even more dangerous than an alter. Add them to task T54921 or as a subtask of that instead.

DBA tag is usually enough yes.

Is that still accurate? That task says (T54921#7092428) to add the tables to be dropped to https://wikitech.wikimedia.org/wiki/Obsolete_or_unneeded_database_tables, should I do that?

I don't think we are doing that anymore.

I am confused - can someone clarify why it says it is done on s1 (enwiki)? Does it refer to removing the code or the table deletion itself?
The table is still there on the replicas:

root@db1132.eqiad.wmnet[enwiki]> show create table pagetriage_log;
+----------------+-------------------------------------------------------------------------------------------------------------------->
| Table          | Create Table                                                                                                       >
+----------------+-------------------------------------------------------------------------------------------------------------------->
| pagetriage_log | CREATE TABLE `pagetriage_log` (
  `ptrl_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `ptrl_page_id` int(10) unsigned NOT NULL,
  `ptrl_user_id` int(10) unsigned NOT NULL,
  `ptrl_reviewed` tinyint(3) unsigned NOT NULL DEFAULT 0,
  `ptrl_timestamp` binary(14) NOT NULL,
  PRIMARY KEY (`ptrl_id`),
  KEY `ptrl_page_id_timestamp` (`ptrl_page_id`,`ptrl_timestamp`),
  KEY `ptrl_timestamp` (`ptrl_timestamp`)
) ENGINE=InnoDB AUTO_INCREMENT=8134354 DEFAULT CHARSET=binary ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8 |
+----------------+-------------------------------------------------------------------------------------------------------------------->
1 row in set (0.001 sec)

I am confused - can someone clarify why it says it is done on s1 (enwiki)? Does it refer to removing the code or the table deletion itself?

Based on the diff: https://phabricator.wikimedia.org/transactions/detail/PHID-XACT-TASK-nzxnh2iydw7osz6/ I think it was filed like that from the beginning.

@kostajh could you clarify the above?

My idea is to rename this table on enwiki to make sure nothing breaks and after a few days, drop it for good.

Thanks

@kostajh could you clarify the above?

Sorry, I just copy/pasted from the example task, looking at the empty checkboxes and not the "Done" suffix. (I don't think we need both a checkbox and "Done" wording fwiw.)

My idea is to rename this table on enwiki to make sure nothing breaks and after a few days, drop it for good.

Sounds good.

@kostajh thanks - so to be clear, this can be done anytime, right?

@kostajh thanks - so to be clear, this can be done anytime, right?

Yes, thanks.

I have renamed this table on an enwiki replica:

root@db2176.codfw.wmnet[enwiki]> rename table pagetriage_log to  T328309_pagetriage_log;
Query OK, 0 rows affected (0.036 sec)

root@db2176.codfw.wmnet[enwiki]>

If nothing breaks - I will get it dropped on Monday.

No errors since Thusday, I am going to proceed with the test wikis first.

Mentioned in SAL (#wikimedia-operations) [2023-03-13T06:52:13Z] <marostegui_> Remove pagetriage_log from testwiki and test2wiki T328309

Took a last minute backup for enwiki as the table is very small.

root@cumin1001:/home/marostegui/T328309# ls -lh
total 37M
-rw-r--r-- 1 root root 37M Mar 13 06:56 pagetriage_log.sql

Change 897571 had a related patch set uploaded (by Marostegui; author: Marostegui):

[operations/puppet@production] filtered_tables.txt: Remove table

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

Mentioned in SAL (#wikimedia-operations) [2023-03-13T07:37:17Z] <marostegui> Remove pagetriage_log from enwiki T328309

Change 897571 merged by Marostegui:

[operations/puppet@production] filtered_tables.txt: Remove table

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

This is all done.
The pending thing here is to remove the clouddb* view - I created T331844 for that