Last modified: 2013-04-02 10:05:20 UTC
I have a mediawiki installation which has been working perfectly for many months. I installed from svn. Each night I have a script that runs svn update maintenance/update.php This week it suddenly started failing with the following error: ... ...have iw_api field in interwiki table. ...iwl_prefix key doesn't exist. ...iwl_prefix_from_title key doesn't exist. ...have cl_collation field in categorylinks table. ...categorylinks up-to-date. Fixing collation for 51 rows. Processing next 50 rows... 0 done. A database query syntax error has occurred. The last attempted database query was: "SHOW MASTER STATUS" from within function "DatabaseBase::getMasterPos". Database returned error "1227: Access denied; you need the SUPER,REPLICATION CLIENT privilege for this operation (mysql.motherhamster.org)" I have not made any recent changes to my LocalSettings.php
By searching through recent svn revisions, i have found that this problem started with revision 83529 james_paige@ravenwest:~/rpg.hamsterrepublic.com/ohrrpgce$ svn log -v -r 83529 ------------------------------------------------------------------------ r83529 | catrope | 2011-03-08 08:47:26 -0800 (Tue, 08 Mar 2011) | 4 lines Changed paths: M /trunk/phase3/includes/db/LoadBalancer.php M /trunk/phase3/maintenance/updateCollation.php Make updateCollation.php a bit less murderous for WMF databases: * Don't run a COUNT(*) query on what's potentially the entire categorylinks table on enwiki (hundreds of millions of rows). Put it in a miser mode check * Wait for DB replication to catch up before processing the next batch. Implemented LoadBalancer::waitAll() for this purpose, which should behave more nicely than wfWaitForSlaves() ------------------------------------------------------------------------ I should note that I do not use replication or load balancing, and I have never configured anything related to masters or slaves.
Roan, ping. ------ Quick grepping indicates that updateCollation is the only maint script that is likely to be run in a non-replicated environment and uses getMasterPos().
r83529 marked fixme.
Fixed in r83874.
I can confirm that the problem is fixed on my wiki. Thanks!
Reopening -- The solution fails on Toolserver (with a MediaWiki configured to use replicated database). It really has two LB-configured database servers: one for global blocking stuff and another for everything else. There's no replication relationship between them (of course) but wfWaitForSlaves() is misled by the server count and tries to do something then fails. liangent@nightshade:~/code/gerrit/mediawiki/core$ php maintenance/eval.php --wiki=zhwiki_p > $lb = wfGetLB(); > print_r($lb->getServerInfo(0)); Array ( [host] => sql-s2-user [user] => liangent [password] => ******** [dbname] => zhwiki_p [type] => ts [load] => 1 [groupLoads] => Array ( [globalblocking] => 0 ) [flags] => 16 ) > print_r($lb->getServerInfo(1)); Array ( [host] => centralauth-p.rrdb [user] => liangent [password] => ******** [dbname] => centralauth_p [type] => ts [load] => 0 [groupLoads] => Array ( [globalblocking] => 1 ) [flags] => 16 ) >
Generally speaking (not to talk about Toolserver), this still happens to users without replication-related stuff configured, but with GlobalBlocking (or anything else who uses LB to connect to a second database server) configured.
Liangent: In general it's better to file a new ticket than reopening one that was closed two years ago, in order to get attention.
(In reply to comment #8) > Liangent: In general it's better to file a new ticket than reopening one that > was closed two years ago, in order to get attention. Should I re-mark this bug as fixed, then create a new one?
