Core Platform Team/Initiative/Mainstash Multi-DC/Epics, User Stories, and Requirements
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on any information on this page. The Core Platform Team and its initiatives do not exist anymore. See MediaWiki Engineering Group instead since 2023. |
- Persistent data storage (not LRU or other space-bounded caching)
- General-case storage
- Specific requirements for particular components will be handled separately (e.g. session storage)
- Most components cannot be configured to use different storage
- Key-value storage matching BagOStuff interface
- key type: string
- value type: string, integer
- Client-set time-to-live (TTL)
- Atomic increment
- Set-if-not-exists (setnx, add)
- Check-and-set
- lock/unlock keys
- get/set/delete batch
- Multi-data-centre access
- read-write in primary data centre
- read-only in secondary data centre(s)
- a single Web request uses only one data centre
- access to different data centres may occur in the same Web session
- All requests for write HTTP methods ( (POST/PUT/DELETE) go to primary data centre
- "datacenter_preferred" cookie provides ~10s affinity for primary data centre after write request
- Synchronous access for web requests
- 10^0 OOM reads per request
- 10^0 OOM writes per request
- Performance
- Current single-DC solution is Redis (10^0 OOM get, 10^2 OOM set)
- Deployment without a noticeable change in performance for end-users
- Minimize code changes required for components of MediaWiki or extensions that access main stash
- add new BagOStuff subclass for this storage
- Configuration for this storage
- Hot migration to new storage
- Retain current stored values and TTLs