|· · ·|
|Declined||Legoktm||T49918 Rename of global (attached) users to existing global usernames|
|Resolved||Reedy||T104686 Unbreak/finish global merge of Yuvipanda into YuviPanda|
|Resolved||Legoktm||T104740 Function: MergeUser::mergeDatabaseTables Error: 1146 Table 'mediawikiwiki.wikilove_log' doesn't exist (10.64.16.27)|
|Resolved||Legoktm||T104739 Function: TranslateHooks::onMergeAccountFromTo Error: 1146 Table 'testwiki.translate_stash' doesn't exist (10.64.16.27)|
|· · ·|
- Mentioned In
- T204747: UserMerge: Code Stewardship Review
T172207: flaggedrevs.fr_user is unindexed
T172204: Add UserMerge support to OAuth
T49918: Rename of global (attached) users to existing global usernames
- Mentioned Here
- T49918: Rename of global (attached) users to existing global usernames
T166028: Rename user "Mlpearc" to "FlightTime" on Central Auth
T167597: Renaming Neoalpha: supervision needed
T168109: Global rename of Smuconlaw → Sgconlaw: supervision needed
T168776: Global rename of Green Cardamom → GreenC: supervision needed
T171474: Global rename of Carrotkit → 胡蘿蔔: supervision needed
T172207: flaggedrevs.fr_user is unindexed
T169527: Global rename of Antero de Quintal → JMagalhães: supervision needed
Fixed on incubatorwiki with:
legoktm@terbium:~$ mwscript eval.php --wiki=incubatorwiki > $renamingUser = User::newFromName('DerHexer'); > $toUser = User::newFromName('YuviPanda'); > $oldUser = User::newFromName('Yuvipanda'); > $um = new MergeUser($oldUser,$toUser, new UserMergeLogger()); > $um->merge($renamingUser); > $um->delete($renamingUser, 'wfMessage');
Will do that on the remaining wikis...
Whats the status? And what is this? https://meta.wikimedia.org/w/index.php?title=Special%3ACentralAuth&target=Yuvipanda The rename is done: https://meta.wikimedia.org/wiki/Special:GlobalRenameProgress/YuviPanda
I repeat what I said at T104686#2855814. Either someone goes wiki by wiki where the merge broke and runs that script or I could go to the same wikis and try MergeUser, although I think the first is preferable as MergeUser is not very stable ATM. Could we please get this resolved? It's been nearly 2 years that @yuvipanda's account was broken... Thanks!
Note that I'm now running into errors like:
yuvipanda@PAWS:~$ pwb.py login Traceback (most recent call last): File "/srv/paws/pwb/pwb.py", line 262, in <module> if not main(): File "/srv/paws/pwb/pwb.py", line 255, in main run_python_file(filename, [filename] + args, argvu, file_package) File "/srv/paws/pwb/pwb.py", line 121, in run_python_file main_mod.__dict__) File "/srv/paws/pwb/scripts/login.py", line 190, in <module> main() File "/srv/paws/pwb/scripts/login.py", line 173, in main site.login(sysop) File "/srv/paws/pwb/pywikibot/site.py", line 2086, in login 'right': self._username[sysop]}) pywikibot.exceptions.NoUsername: Logged in on wikipedia:test via OAuth as YuviPanda, but expect as Yuvipanda <class 'pywikibot.exceptions.NoUsername'> CRITICAL: Closing network session. yuvipanda@PAWS:~$
so it would be nice to fix :)
I am removing the DBA tag, as the number of edits is really low, so there should be no issues with the databases here.
When there is a large number of edits (more than 40k) we do appreciate the heads up so we can monitor the slowest slaves, as some lag might happen.
As this is not the case, removing it.
I will remain subscribed to the task though, just in case.
@Jdforrester-WMF I do not like to be insulted. Are you aware of our Code of Conduct? Stop asuming bad faith from fellow volunteers. It is the second time I receive this kind of replies from you and comming from a paid member of our staff is embarrasing. You also sidetrack with "risk to life or limb". Are you serious? @yuvipanda was fine with having his account locked for a while, not for two years; and it's blocking his work as he said above. If you care to see on many other tasks same problems have been cause for UBN use; so please instead of insinuating that I or any other fellow volunteers working for nothing are abusing things, think twice and do not treat us with such contempt. Thank you.
Sure - I appreciate the heads up, and we, DBAs, normally want to get involved, but as this request didn't involve many edits, DBAs are probably not needed or should not block this :-)
As I said, I will remain subscribed just in case
A recent user merge operation caused 5 minutes of lag on s4 and 5m-1h of lag on dewiki:
Apparently, such an opperation runs the query UPDATE /* MergeUser::mergeDatabaseTables */ flaggedrevs SET fr_user = 'XXXXXX' WHERE fr_user = 'XXXXX', which goes over 64 million rows unindexed and not batched (even if no rows are updated). That would be a hard blocker for future runs.
-- This stores all of our revision reviews; it is the main table -- The template/file version data is stored in the next two tables CREATE TABLE IF NOT EXISTS /*_*/flaggedrevs ( -- Foreign key to revision.rev_id fr_rev_id integer unsigned NOT NULL PRIMARY KEY, -- Timestamp of revision reviewed (revision.rev_timestamp) fr_rev_timestamp varbinary(14) NOT NULL default '', -- Foreign key to page.page_id fr_page_id integer unsigned NOT NULL, -- Foreign key to user.user_id fr_user integer unsigned NOT NULL, -- Timestamp of review fr_timestamp varbinary(14) NOT NULL, -- Store the precedence level fr_quality tinyint(1) NOT NULL default 0, -- Store tag metadata as newline separated, -- colon separated tag:value pairs fr_tags mediumblob NOT NULL, -- Comma-separated list of flags: -- dynamic: conversion marker for inclusion handling (legacy schema had fr_text with PST text) -- auto: revision reviewed automatically fr_flags tinyblob NOT NULL, -- Parameters for revisions of File pages: -- Name of included image (NULL if n/a) fr_img_name varchar(255) binary NULL default NULL, -- Timestamp of file (when uploaded) (NULL if n/a) fr_img_timestamp varbinary(14) NULL default NULL, -- Statistically unique SHA-1 key (NULL if n/a) fr_img_sha1 varbinary(32) NULL default NULL ) /*$wgDBTableOptions*/; CREATE INDEX /*i*/fr_page_rev ON /*_*/flaggedrevs (fr_page_id,fr_rev_id); CREATE INDEX /*i*/fr_page_time ON /*_*/flaggedrevs (fr_page_id,fr_rev_timestamp); CREATE INDEX /*i*/fr_page_qal_rev ON /*_*/flaggedrevs (fr_page_id,fr_quality,fr_rev_id); CREATE INDEX /*i*/fr_page_qal_time ON /*_*/flaggedrevs (fr_page_id,fr_quality,fr_rev_timestamp); CREATE INDEX /*i*/fr_img_sha1 ON /*_*/flaggedrevs (fr_img_sha1);
We should fork that off into a new seperate bug
Oh, this was done as a merge, not a rename... Not quite sure why. Some artefact of SUL finalisation? Was there two Yuvi accounts onwiki?
A rename wouldn't touch the flaggedrevs table in question, so wouldn't have been a problem before
As I said before, for normal renames (which as per T104686#3490070 doesn't look like this was a normal one) we haven't seen any issues at all on the last renames, which had quite lots of edits:
While T172207 needs to get fixed, I am not sure if it is a blocker for a normal rename.
@Marostegui That's because this was not just a rename but a global user merge. Yuvipanda and YuviPanda were two different accounts and when the Global User Merge feature was enabled it seems we tested on them how the merging of two global accounts would work. As such the system has to merge the edits of one account to another then delete the former user. Given this issue and others we ran into, global username merges have been disabled and we're no longer using this nor there are plans to reactivate it in the future (cf. T49918#1933044). So far I think this has been the only case on production wikis (we did some at the beta cluster before this tool go live) and as such I don't think there's any "danger" in this situation to repeat, at least not in the near future. It seems it was good however to have a DBA subscribed here ;-) Thanks to all who helped. Regards.