I'm strongly in favor of getting rid of the mess that is $wgSharedTables. Any mechanism that supports sharing tables needs to be designed to be aware of that, using appropriate methods to get database handles that are documented as being on possibly different databases. The caller would at least know that certain tables are co-located.

The virtual domain config and virtual domain aware connection methods indeed seem like they fit this use case. Anything actually designed to support table sharing can be converted to using the getPrimaryDatabase()/getReplicaDatabase() methods.

@aaron I support removing wgSharedTables. To my knowledge it is in practice only used for sharing user tables, which we're perhaps better off doing explicitly instead of pretending that we allow any arbitrary table to be shared. Which is maintenance-heavy at best, and a footgun at worst.

Can this work without requiring sysadmins to hardcoded a lot of entries internal table names? Assuming the same virtual domain can be used for multiple tables, I guess yes. E.g. we'd register virtual-user akin to how we have virtual-botpasswords in core already, and use it for user/actor/user_properties/etc accordingly.

In terms of configuration, that would turn $wgSharedDB effectively into a a boolean feature flag, much like how it is already. Except no longer configurable via wgSharedTables but rather specifically for shared user accounts, automatically plugged into $wgVirtualDomainsMapping['virtual-user'] or something like that, for compat.

Apparently SpamRegex and MultiMail also make use of shared tables.

In MediaWiki core, shared tables mainly rely on this Setup.php hack turning the table name into an alias via LoadBalancer::setTableAliases(). That's probably not possible to port to the virtual domain mechanism (we could use $wgVirtualDomainsMapping as the place to declare shared tables but the way that configuration gets used would differ from all other virtual domains), short of rewriting all queries with a join that involves both non-shared and shared tables. So maybe this task is not feasible after all.

Another option would be to deprecate without replacement, and create a small authentication extension that uses a shared table for passwords and emails, like CentralAuth. That and the user group part of T359116: Split up CentralAuth into smaller extensions would cover 99% of $wgSharedDB use cases, I think.

Pinging MediaWiki-Engineering to decide on how to procede with this. The idea sounds good, but there are questions about migrationg existing installations and how this would interact with CentralAuth.

@daniel Did you get an answer? MWI is part of MWE so I'm unsure whether you meant MPT or MWE. It got moved back to MWI, so I'm guessing something was said or decided?

In T355376#10082288, @Krinkle wrote:

@daniel Did you get an answer? MWI is part of MWE so I'm unsure whether you meant MWT or MWE. It got moved back to MWI, so I'm guessing something was said or decided?

No, I think this got stuck. Also, the only person on MWI really into this stuff is Aaron. Perhaps this would be a good topic for next week's Principal's office hours?

I made the task more generic and not about one specific replacement, and left a link to it at the relevant config documentation pages.

It would definitely be a detrimant to multiple large-sized wiki-farm services (like Miraheze, Wiki.gg, WikiOasis and Wikia and independent wiki hosting projects that share their user tables and other appropriate tables across multiple small or large-scale topic related wikis that can't easily be condensed into one larger wiki, (see the Classic RuneScape Wiki, the Old School RuneScape Wiki and the RuneScape Wiki as a small topic related example project that utilises $wgSharedDB to connect all three wikis to the same user tables) I believe it would be in Wikimedia's best interests to keep supporting $wgSharedDB.

If you are going to deprecate $wgSharedDB, then I believe it serves the best interest of most if not all MediaWiki users, especially those that utilise one of the three major wiki-farm services around the world that utilises $wgSharedDB to have a replacement, rather than it be an afterthought or a project that no one wants to deal with and gets put on the afterburner for ten to twenty years. Most people already don't want to deal with Extension:CentralAuth as a way of sharing user tables and attempting a hacky SSO method, it's best not to force people to have to use it, unless T359116 will improve upon the functionality of CentralAuth once its dissected into smaller components, but I definitely believe Wikimedia shouldn't just deprecate it without a viable replacement, it would cause more issues than it solves in the long-term.

In T355376#9670539, @Tgr wrote:

Apparently SpamRegex and MultiMail also make use of shared tables.

Note that MultiMail supports shared tables as a convenience for existing installations using shared tables; it doesn't require them. For the purposes of this task, feel free to ignore it.