The maintain-replicas.pl script is used to create a number of views on labsdb. This script has not been run for some new labs replicas (including adywiki) and thus they lack those views.
$ sql adywiki_p ERROR 1049 (42000): Unknown database 'adywiki_p'
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| operations/software | master | +38 -62 | [DNM] hack maintain-replicas.pl for adywiki/jamwiki |
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Open | Jdrewniak | T128546 [Recurring Task] Update Wikipedia and sister projects portals statistics | ||
| Stalled | None | T59617 Make watchlist table available as curated foo_p.watchlist_count on labsdb | ||
| Resolved | Krenair | T134017 Create Wikipedia Jamaican | ||
| Resolved | ori | T135029 adywiki and jamwiki are missing the associated *_p databases with appropriate views | ||
| Restricted Task | ||||
| Resolved | • chasemp | T138450 maintain-replicas.pl unmaintained, unmaintainable | ||
| · · · |
it's a "labsdb" thing afaict.
one hit in entire wikitech " springle: ran operations/software maintain-replicas.pl and fedtables.pl on labsdbs"
Hi!
Checking on the progress of this ticket...
We're waiting for this to be looked at / fixed before we can update the wikipedia.org portal stats.
Thanks!
This is not a DBA ticket, I made sure that replica was working and safe (filtered) literally hours after the wiki was setup:
$ mysql -h labsdb1001 adywiki -e "SELECT max(rc_timestamp) FROM recentchanges" +-------------------+ | max(rc_timestamp) | +-------------------+ | 20160516125342 | +-------------------+
I suppose some cron/script maintenance on Cloud-Services may be failing to execute?
What worries me is that, what I suppose is a core production service depends on a non-core service; and it is not running on the analytics or vslow core production host(!). Of course this particular issue should be fixed, but could you clarify the usage needs for the portal?
That's useless without the adywiki_p views.
I'm not aware of anything failing to execute, I think ops haven't attempted to execute the script.
The portal thing? I think they generate the stats in labs and upload static pages to production.
Can someone update this task description? As-is I have no idea what's going on here. I know this is in large part because of my own lack of contextual knowledge on the labsdb use case in question but this task is cryptic at best.
What is this intended to do?
Hi there - we need to update the stats on the wikipedia.org portal page on a regular basis. We've recently found that the script we run to do this isn't actually catching the updated stats for us to put into production.
I've edited the description back. The issue in this ticket is unavailability of adywiki replicas. The updates are discussed in a blocked ticket. Portals is far from the only thing that's affected or can possibly be affected by this issue.
@jcrespo this is a bit shrouded in mystery with no documentation. It seems post replication someone would run maintain-replicas.pl manually but no one around now may have ever done it.
@jcrespo this is a bit shrouded in mystery with no documentation. It seems post replication someone would run maintain-replicas.pl manually but no one around now may have ever done it.
@coren , any chance you can help a bit with that ? I think just a few guiding pointers would be greatly appreciated.
Summary of a discussion with @ori:
The maintain-replicas script creates a new schema that contains only tables that needs to be replicated and only the columns from those tables that needs to be replicated, ensuring in the process that sensitive data is not made available to labs users.
The current maintain-replicas script needs some refactoring / rewriting. The lack of separation between configuration and logic makes it difficult to update the list of tables / columns replicated. The list of databases is read directly from the script, it should be externalized so that we can run that script on a specific database.
At the minimal, we need to be able to run that script on a single database to limit risk.
I agree, although it needs to be a separate ticket and I don't think we can justify blocking this on a full rewrite, given that it's been run before. The script not only needs to deal with those views but it also needs to update the meta_p table. I guess we could could replace the section where it reads all.dblist with some hack setting up just adywiki and jamwiki, and remove the sql("DELETE FROM meta_p.wiki;");.
Change 295564 had a related patch set uploaded (by Ori.livneh):
[NOT FOR MERGING] hack maintain-replicas.pl for adywiki/jamwiki
Sample invocation:
$ DB_USER=root DB_PASS=password perl maintain-replicas.pl 2> T135029.sql
Mentioned in SAL [2016-06-22T22:25:04Z] <ori> Ran hacked maintain-replicas.pl on labsdb100[13] for T135029
I ran it against labsdb1001 and labsdb1003 and it seems to have done the trick. labsdb1002's MySQL instance isn't running, so that one was not updated.
Thank you @ori! I believe the issues with labsdb1002 are T126946: disk failure on labsdb1002
Filed T138450: maintain-replicas.pl unmaintained, unmaintainable for tracking issues with the script.
Change 295564 abandoned by Ori.livneh:
[DNM] hack maintain-replicas.pl for adywiki/jamwiki
No, the proper version of the script was replaced in T138450, Ori's DNM version of the old script was useful for this but is no longer necessary.