If we will have a default MainStash solution, we need to make that solution Multi-DC aware.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
It seems like most or all of the components that now use MainStash will instead use WanCache, db-replicated, or db-replicated with a JobQueue. If all of them will, it doesn't make sense to craft a storage solution that is unused. Instead, we could wire MainStash to mcrouter (or db-replicated), and just watch for new extensions or components that use MainStash and make sure that they're not losing too much data.
This mostly depends on if there will be any components that use MainStash after @aaron is done porting.
Comment Actions
I think right now it looks like we won't have any code using MainStash on WMF servers.
There's a possibility that in the future someone will deploy an extension that uses MainStash on WMF servers, and they will be bummed that it's not multi-DC capable.
I see several options here:
- Remove MainStash interface from core
- Configure WMF servers to have a MainStash implementation that just throws an error like, "Someone's using MainStash which is not allowed!"
- Configure WMF servers to use a sub-optimal but working MainStash implementation, like the MySQL backend
- Create and deploy a storage service for MainStash that is Multi-DC aware like Kask, even though nothing uses it right now
- Do nothing and hope that our future selves or colleagues will remember to check extensions and core code to see if they use MainStash before deploying them
Of these, I prefer the third (main stash in MySQL) since it's robust to institutional memory loss and only requires a small configuration change to implement.
Comment Actions
Aaron, I'm untagging us from this. Not sure if there's anything else to do here. I'd feel more comfortable having a multi-DC default here just-in-case, but happy to leave it up to you.
Comment Actions
@EvanProdromou: Assuming this task is about MediaWiki-General, hence adding project tag so others can find this task when searching for tasks under that project or looking at that project workboard.
Comment Actions
The main stash already has a stock default that satisfies its contract in terms of persistence and replication
DefaultSettings.php
$wgMainStash = 'db-replicated';
This in contrast to regular caching, which is expected to not be "worth" falling for to the DB, and hence WANObjectCache defaults to CACHE_NONE if the site operator does not point it to Memcached, Redis or some other shared store.
The only reason this was an issue for WMF is because we wanted a ligher backend for main stash and thus used Redis instead, with the expectation that we'll use Redis' replication capabilties across DCs. However as we now know, that didn't work out very well.
As such for anything with more than a trivial amount of traffic, we either moved WMF-deployed consumers to either coope with less strict guruantees (Memcached, APC, etc.), or by using a deferred update/job instead for the writes, or by creating a dedicated service (like for sessions and echo).
For the low volume and general satisfaction of the interface we can probably just restore the default of db-replicated. This is tracked at T212129. This requires that we fix support for makeGlobalKey() in SqlBagOStuff which Aaron is already working on.