Page MenuHomePhabricator

Apply outstanding schema changes for "objectcache" tables in production (exptime, flags, modtoken)
Closed, ResolvedPublic

Description

  1. Alters to run:
  1. Where to run those changes:
    • Core MW tables of all wikis: all.dblist
  2. When to run those changes: At any time
  3. If the schema change is backwards compatible: No
  4. If the schema change has been tested already on some of the test/beta wikis: Tested in beta cluster.
  5. if the data should be made available on the labs replicas and/or dumps: Not sure

This table is barely used and should not have much read and write on it (and be empty IIRC). It should be also truncated and locked before applying if it's not empty.

Progress:

  • s1
  • s2
  • s3
  • s4
  • s5
  • s6
  • s7
  • s8
  • pc1
  • pc2
  • pc3

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I haven't had time to look at it with all of the craziness of the world but it has been on my (very long) todo list since February.

No worries, just double checking tasks we want/can prepare before the switchover :)

I suggest waiting with this until https://gerrit.wikimedia.org/r/c/mediawiki/core/+/666780/24 can roll out at which point we can probably just do a one-time purge of whatever is in these tables (maybe in small groups of wikis, with a day in-between to reduce the load a bit).

Ref T212129: Move MainStash out of Redis to a simpler multi-dc aware solution.

Once that work is done, we may also be moving some of these features to use MainStash (which will then be on x2 mysql instead of Redis), instead of objectcache on core tables (as done currently via CACHE_DB or 'db-replicated', instead of MainStash).

In proving and preparing for this, we actually moved some additional features from MainStash-Redis to CACHE_DB, but I think it would make sense to then move those further to MainStash.

Doing that will implicitly de-reference much of what's there anyway, at which point we can truncate whatever is left then. (Instead of truncating multiple times, once for the alter, and then again implicitly by moving the backend pointer to mainstash).

I assume we'd want varbinary(14), so that it can store "infinity".

Removing myself from this task, as this is waiting for @Ladsgroup to investigate when he's got time for it.

I looked at this.

It's three distinct problems (I admit I looked at frwiki only but for most places it should be the same).

  • echo seen
    • We can simply drop those, the high TTL to 2038 is fixed by I99230d2351b40751a3f2f5123c5f38693120259e and the values are not being read anymore as they have been migrated to kask. I can't find a way to see when it was actually set to mysql but it was possibly a blip. The funny thing is that function that creates the key says it's memcached but it was never on memcached as far as I can see.
  • :page-recent-delete: this is important and better not be deleted but I don't know why it's not migrated to mainstash.
  • I do see a lot of frwiki:twoColConflict_yourText:foo:123 and that definitely needs to be migrated to mainstash or memcached. I'll create a ticket for the team for it to take a look.

Does my assessment look correct @Krinkle?

Krinkle renamed this task from Alter objectcache.exptime to Apply outstanding schema changes for "objectcache" tables in production (exptime, flags, modtoken).Dec 22 2021, 6:51 PM
Krinkle updated the task description. (Show Details)
Krinkle updated the task description. (Show Details)

I added x2 to the list, but then removed it again. Upon checking I realize we hadn't yet created these tables on the x2 cluster in the first place (mainly because it's non-obvious which database name it would need to go under.) I'll handle that on the parent task and remove this as blocker for MainStash DB.

Mentioned in SAL (#wikimedia-operations) [2022-01-05T13:33:44Z] <Amir1> delete echo keys from objectchange in frwiki (T272512)

Mentioned in SAL (#wikimedia-operations) [2022-01-05T13:33:44Z] <Amir1> delete echo keys from objectchange in frwiki (T272512)

I cleaned it on all of s6 now.

Mentioned in SAL (#wikimedia-operations) [2022-01-10T10:16:22Z] <Amir1> removing echo objectcache entries on all wikis (T272512)

Change 753003 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/core@master] page: Use MainObjectStash instead of 'db-replicated' cache

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

Change 753003 merged by jenkins-bot:

[mediawiki/core@master] page: Use MainObjectStash instead of 'db-replicated' cache

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

Change 754602 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/core@wmf/1.38.0-wmf.17] page: Use MainObjectStash instead of 'db-replicated' cache

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

Change 754602 merged by jenkins-bot:

[mediawiki/core@wmf/1.38.0-wmf.17] page: Use MainObjectStash instead of 'db-replicated' cache

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

Mentioned in SAL (#wikimedia-operations) [2022-01-18T09:32:41Z] <ladsgroup@deploy1002> Synchronized php-1.38.0-wmf.17/includes: Backport: [[gerrit:754602|page: Use MainObjectStash instead of 'db-replicated' cache (T272512)]] (duration: 00m 56s)

Change 755450 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/extensions/AbuseFilter@master] Use MainStash instead of db-replicated

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

Change 755450 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] Use MainStash instead of db-replicated

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

Change 756083 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/extensions/AbuseFilter@wmf/1.38.0-wmf.18] Use MainStash instead of db-replicated

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

Change 756083 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@wmf/1.38.0-wmf.18] Use MainStash instead of db-replicated

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

Mentioned in SAL (#wikimedia-operations) [2022-01-24T15:48:40Z] <ladsgroup@deploy1002> Synchronized php-1.38.0-wmf.18/extensions/AbuseFilter/includes/ServiceWiring.php: Backport: [[gerrit:756083|Use MainStash instead of db-replicated (T272512)]] (duration: 00m 49s)

Change 763240 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/core@master] upload: Migrate uploadstatus entry to MainObjectStash instead of db

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

Change 763240 merged by jenkins-bot:

[mediawiki/core@master] upload: Migrate uploadstatus entry to MainObjectStash instead of db

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

Change 766559 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/extensions/Translate@master] Avoid writing to objectcache table

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

Change 766559 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] Avoid writing to objectcache table

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

The table is fully cleaned now. Nothing writes to it anymore in any wiki.

Marostegui changed the task status from Stalled to Open.Mar 9 2022, 8:35 AM

@Ladsgroup confirm this is good to go?
I have checked the table on frwiki and it is indeed now empty (and same for parsercache)

We'd also need the ALTER for flags and modtoken columns.

I don't know about ParserCache table. That's another beast I don't want to tackle atm. But objectcache should be fine to go.

What do you mean?
As far as I can see we need to alter objectcache table on sX and on pcX - not the pcXXX tables.

Why do we have objectcache table on pcX? Which wiki they belong to? Why our infra is so inconsistent 😭

I need to check those (and maybe we can drop the table there?) but for sX it should be fine.

Why do we have objectcache table on pcX? Which wiki they belong to? Why our infra is so inconsistent 😭

You tell me :-)
So that one shouldn't be altered?

I need to check those (and maybe we can drop the table there?) but for sX it should be fine.

I will leave it out for now then
But we need to get the column definition for flags and modtoken.

I will work on this one too.
Altered s6 (all wikis). Giving it 24h to settle just in case

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.

Change 769461 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] docs: Document how SqlBagOStuff::createTables() works

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

The core objectcache tables, parsercache table shards, and mainstash DB are all backed by the same schema and SqlBagOStuff interface. Having said that, the new features for which this particular schema addition was drafted are unlikely to be needed for ParserCache any time soon so it's certainly fine to post-pone that for now. Although for consistency, transparency, and reduced code complexity it would make sense to apply "eventually". The longer we wait, the more risk from accidental misunderstandings or assumptions about what the state of any given table is.

The pc% tables were originally, or intended to be, initialised by SqlBagOStuff::createTables(). I've just pushed a comment to document this more clearly. It works by running CREATE TABLE pc123 LIKE objectcache; after running the standard objectcache.sql on each database. However, it seems we no longer have that file. And yes this means each pc database has an empty objectcache table that is simply an empty template. This is not required or useful now, but it is a known and expected innocent side-effect.

Sure, it can be done easily as they are empty. We should research though if they can or need to be deleted in order to also reduce confusion like the one we had on this ticket.

Marostegui updated the task description. (Show Details)

All done, including parsercache

Change 769461 merged by jenkins-bot:

[mediawiki/core@master] docs: Document how SqlBagOStuff::createTables() works

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