Change Details

### Background It is unclear to me what behaviour is expected from admins that set this variable, and I suspect that it is quite likely that those who do have expectations for it, are in fact not getting it. (Which hopefully means they avoid it, but more likely means they're experiencing issues without realising it or its cause). I guess at a basic level, this (optional) configuration variable overrides the keyspace used by BagOStuff instances for cache keys, which otherwise defaults to the Wiki ID (usually identical to the string form of the DB Domain). The original justification for this, from [r97468](https://www.mediawiki.org/wiki/Special:Code/MediaWiki/97468) and [r105523](https://www.mediawiki.org/wiki/Special:Code/MediaWiki/105523) (cc @tstarling, @aaron). >>! @Nikerabbit wrote in September 2011: > I'm overriding wfWikiID to run multiple instances on same database > but with different settings, and I don't want to them mess each others caches. ### Problem The expectation to separate caches in this manner falls apart when you consider global cache keys (previously known as "shared" or "foreign" cache keys). These use the a constant prefix `global`, and generally utilize the Wiki ID as one of the key segments if the information varies by wiki. At a fundamental level, I believe MediaWiki does not support this kind of separation, with cache keys perhaps being merely the most noticible area where it breaks down. In general, I think, we assume the Wiki ID to be globally unique within the scope of things that MediaWiki internally interacts with (db, caches, file system, etc.) As such, to facciliate something like this, the two wikis should be given a distinct wiki ID. Or, if one really wants to have identical clusters operating independently where two wikis have the same db name (and thus presumably have dedicated and separate MySQL servers), then they should also have separate Memc instances. Some additional background in T269226 (currently restricted).

### Background It is unclear to me what behaviour is expected from admins that set this variable, and I suspect that it is quite likely that those who do have expectations for it, are in fact not getting it. (Which hopefully means they avoid it, but more likely means they're experiencing issues without realising it or its cause). I guess at a basic level, this (optional) configuration variable overrides the keyspace used by BagOStuff instances for cache keys, which otherwise defaults to the Wiki ID (usually identical to the string form of the DB Domain). The original justification for this, from [r97468](https://www.mediawiki.org/wiki/Special:Code/MediaWiki/97468) and [r105523](https://www.mediawiki.org/wiki/Special:Code/MediaWiki/105523) (cc @tstarling, @aaron). >>! @Nikerabbit wrote in September 2011: > I'm overriding wfWikiID to run multiple instances on same database > but with different settings, and I don't want to them mess each others caches. ### Problem The expectation to separate caches in this manner falls apart when you consider global cache keys (previously known as "shared" or "foreign" cache keys). These use the a constant prefix `global`, and generally utilize the Wiki ID as one of the key segments if the information varies by wiki. At a fundamental level, I believe MediaWiki does not support this kind of separation, with cache keys perhaps being merely the most noticible area where it breaks down. In general, I think, we assume the Wiki ID to be globally unique within the scope of things that MediaWiki internally interacts with (db, caches, file system, etc.) As such, to facciliate something like this, the two wikis should be given a distinct wiki ID. Or, if one really wants to have identical clusters operating independently where two wikis have the same db name (and thus presumably have dedicated and separate MySQL servers), then they should also have separate Memc instances. For example, one could invoke memcached twice on the same server with differnet ports. Some additional background in T269226 (currently restricted).

### Background It is unclear to me what behaviour is expected from admins that set this variable, and I suspect that it is quite likely that those who do have expectations for it, are in fact not getting it. (Which hopefully means they avoid it, but more likely means they're experiencing issues without realising it or its cause). I guess at a basic level, this (optional) configuration variable overrides the keyspace used by BagOStuff instances for cache keys, which otherwise defaults to the Wiki ID (usually identical to the string form of the DB Domain). The original justification for this, from [r97468](https://www.mediawiki.org/wiki/Special:Code/MediaWiki/97468) and [r105523](https://www.mediawiki.org/wiki/Special:Code/MediaWiki/105523) (cc @tstarling, @aaron). >>! @Nikerabbit wrote in September 2011: > I'm overriding wfWikiID to run multiple instances on same database > but with different settings, and I don't want to them mess each others caches. ### Problem The expectation to separate caches in this manner falls apart when you consider global cache keys (previously known as "shared" or "foreign" cache keys). These use the a constant prefix `global`, and generally utilize the Wiki ID as one of the key segments if the information varies by wiki. At a fundamental level, I believe MediaWiki does not support this kind of separation, with cache keys perhaps being merely the most noticible area where it breaks down. In general, I think, we assume the Wiki ID to be globally unique within the scope of things that MediaWiki internally interacts with (db, caches, file system, etc.) As such, to facciliate something like this, the two wikis should be given a distinct wiki ID. Or, if one really wants to have identical clusters operating independently where two wikis have the same db name (and thus presumably have dedicated and separate MySQL servers), then they should also have separate Memc instances. For example, one could invoke memcached twice on the same server with differnet ports. Some additional background in T269226 (currently restricted).