This is currently giving:
Table 'fawiki_p.linktarget' doesn't exist
Also we need to make sure tl_target_id in templatelinks is also replicated.
(Which project tag is the best for this ticket?)
Description
Description
Details
Details
Related Changes in Gerrit:
Customize query in gerrit
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Ladsgroup | T300222 Implement normalizing MediaWiki link tables | |||
| Resolved | Ladsgroup | T299417 Normalize templatelinks table | |||
| Resolved | Ladsgroup | T305064 Make linktarget table visible on cloud wiki replicas |
Event Timeline
Comment Actions
As far as I can tell from the code so far, linktarget rows don’t get deleted even when they’re no longer used – but the replicas should probably only make rows visible that have at least one incoming link, to avoid disclosing information that shouldn’t be public.
Comment Actions
Indeed - I think this needs an approach to similar to what we do with actor, so only show the linktarget rows that are referenced in other links* tables.
Comment Actions
That is definitely in the medium-term work (=in a couple of months) to avoid bloating the table but it has complexities (race condition between being used and being deleted) that make it require a bit a time.
Comment Actions
Hi, Can I ask a bump here? I'm slowly starting to stop writing to the old system and I need ample time between this and that so users can migrate their tools.
Comment Actions
Change 788278 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):
[operations/puppet@production] wikireplicas: Add linktarget to maintain-views
Comment Actions
Change 788278 merged by Ladsgroup:
[operations/puppet@production] wikireplicas: Add linktarget to maintain-views
Comment Actions
Change 789291 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):
[operations/puppet@production] dbproxy: Repool the old batch, Depool the new one
Comment Actions
Change 789291 merged by Ladsgroup:
[operations/puppet@production] dbproxy: Repool the old batch, Depool the new one
Comment Actions
Change 789308 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):
[operations/puppet@production] dbproxy: Repool clouddb10(17|18|19|20)
Comment Actions
Change 789308 merged by Ladsgroup:
[operations/puppet@production] dbproxy: Repool clouddb10(17|18|19|20)
Comment Actions
I’d be very interested in this, since I think we should perhaps use a similar approach for the Wikibase term storage. Currently, we delete rows there as soon as they become unused, with some locking scattered around the code to try to ensure that we don’t delete terms that have just become used again. I think our current code is mostly correct, but it might still be better to remove most of the locking, leave unused terms in the production table, filter them from the public views on the replicas, and later somehow™ clean up the table asynchronously while still avoiding this race condition. Perhaps we can use the same code, or at least the same approach, as the linktarget table.