I think it should be something to set at the *BagOStuff level. MediumSpecificBagOStuff has the concept of a configurable keyspace, which is then inherited by the other classes, but MediumSpecificBagOStuff::makeGlobalKey() hardcodes the keyspace to global.

I think the right way would be to add a 'globalkeyspace' parameter (by default 'global') through which one could configure two wikis to have separate world views even when using the same memcached cluster.

Change 754909 had a related patch set uploaded (by RhinosF1; author: RhinosF1):

[mediawiki/core@master] Allow variants of GLOBAL_KEYSPACE for BagOStuff

https://gerrit.wikimedia.org/r/754909

@RhinosF1 I'm not sure I understand the use case. Are you saying Miraheze is running two separate wiki farms (which share nothing in common, e.g. no FileRepo/InstantCommons, no Global* things like CentralAuth, GlobalUsage, GlobalUserPage, etc.) but point to the same Memcached servers?

If yes, I think the way to support that would be to run multiple instances of Memcached on different ports of the same server, and allocate them the appropiate memory, and configure them accordingly via the existing configuration variables.

Alternatively, if this is this a single wiki farm with the CentralAuth aspect of it split (e.g. each wiki belongs to one of two halves of the farm), then that is something currently not supported and could cause all kinds of bugs and corruption, not to mention security issues. However, depending on how much cost it would incurr on the complexity and maintenance of CentralAuth, it may be viable to introduce a configuration variable like wgCentralAuthSplitByDb = true;, which would trigger various code paths to consider wgCentralAuthDatabase part of cache keys and maybe other identifiers where we store or associate something in a way that could otherwise cause the other CA cluster to be confused. I suppose we would still need to require that wiki-id be globally unique, however, I assume that's okay.

They share the same backend infra. So databases, memcache, redis for jobs, fine storage. All the separation is done software layer. (The actual mediawiki install is also seperate). Mainly because hardware costs.

The wiki-id can be assumed unique yes.

I've since chatted with RhinosF1 about Miraheze's setup. As I undertand it, there are already multiple instances of Memcached in-use. I've made a few suggestions that would help them improve stability of their user sessions (regular cache data was competing against those in Memc's LRU), and to carve out a small memcached process just for their test wiki(s).

Relevant code and changes: https://github.com/miraheze/mw-config/commits/master/GlobalCache.php

@RhinosF1 @Universal_Omega How's it going now?

I've not seen the issues since the changes. UO has been away.

Change 754909 abandoned by RhinosF1:

[mediawiki/core@master] objectcache: Make BagOStuff::makeGlobalKey prefix configurable

Reason:

https://gerrit.wikimedia.org/r/754909