Labs database replica drift
Open, Needs TriagePublic

Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJun 29 2016, 5:22 PM
Anomie added a subscriber: Anomie.Jun 29 2016, 6:23 PM

May I ask you to please copy the query here to check the drift? We keep here the older subtasks only because they are older than this one, but following a single format will help speed up the resolution of all issues (it would be almost impossible to handle one ticket per row with issues). Thank you in advance- I am just trying to respond quickly to all issues!

russblau added a subscriber: russblau.EditedNov 5 2016, 2:11 PM
MariaDB [enwiki_p]> select page_title from page join pagelinks on pl_from = page_id where page_namespace=0 and pl_namespace = 0 and pl_title="Will_Johnson";
+----------------------------------+
| page_title                       |
+----------------------------------+
| Denver_Broncos                   |
| List_of_current_AFC_team_rosters |
| Will_Johnson_(disambiguation)    |
| William_Johnson_(rugby_player)   |
| Will_Johnson_(American_football) |
| Johnson,_Will                    |
| 2016_Denver_Broncos_season       |
+----------------------------------+
7 rows in set (0.01 sec)

The comparable query to the enwiki API yields only 4 incoming links.

https://en.wikipedia.org/w/api.php?action=query&list=backlinks&bltitle=Will_Johnson&blnamespace=0&format=jsonfm

@russblau Thanks for the report- it is 5 as we speak, but it is indeed wrong. This and hopefully all drift issues are fixed on the imports on the new labsdb servers T147052, that I hope they will be soon available.

jcrespo moved this task from Triage to Meta/Epic on the DBA board.Nov 10 2016, 1:16 PM

https://quarry.wmflabs.org/query/5979

This as of 30 Novemeber 2016 is showing 45 rows that the query says are 'orphaned' but when checked on English Wikipedia certainly arent.

Revent added a subscriber: Revent.Jan 25 2017, 1:54 AM

I was asked to mention this here, although I'm unsure if it's actually a 'replication' issue.

https://quarry.wmflabs.org/query/14916 reports 35 entries in the transcode table, all for files that were uploaded to Commons in 2013, and then renamed while still being transcoded. This created 'orphaned' entries in the transcode table.

AFAICT, the bug that caused this seems to have been long ago fixed, as the examples here are all from 2013. Before the recent cleanup that's been going on with old failed transcodes, there were many other entries here, all related to files that had been deleted while being transcoded. These were easily fixed by simply undeleting and redeleting the file, a couple of months ago. The entries were all, also, from years ago... I suspect these were the relics of fixed bugs, in the database.

There seems to be no way from the 'admin' end to fix these entries, as they are for redirects, not videos.... they could probably usefully simply be deleted from the DB, and then we can watch to see if it recurs.

The particular search is relevant, however, as both times recently where the video scaler system was reset (last month, and earlier this month) all 'running' transcodes were populated into it.... they were shown as 'completed' on the file pages, but there were reports (such as T154186) that supposedly successfully transcoded videos would not play. Requeueing the videos, so that they were transcoded again, seemed to fix the issue.

Resetting a transcode, while it is running, also results in it ending up in this search.

This also seems to be a bug, but a somewhat useful one.

@Revent: As the production database servers return the same result, this has nothing to do with labs replication.

@Revent then I missunderstood you, we should file a proper, standalone bug.