From b18121d98c20ec76c9edc9b606f77405e19dd411 Mon Sep 17 00:00:00 2001 From: Timo Tijhof Date: Wed, 25 Sep 2024 15:10:51 -0700 Subject: rdbms,objectcache: Replace wgChronologyProtectorStash with MicroStash Bug: T336004 Change-Id: I2f769aa703ce98b15fa0fe98eda092ff19c27d0a --- includes/MainConfigSchema.php | 46 ++++++++++++++++++------------------------- 1 file changed, 19 insertions(+), 27 deletions(-) (limited to 'includes/MainConfigSchema.php') diff --git a/includes/MainConfigSchema.php b/includes/MainConfigSchema.php index f015144e45c7..bcda2093a553 100644 --- a/includes/MainConfigSchema.php +++ b/includes/MainConfigSchema.php @@ -4010,15 +4010,27 @@ class MainConfigSchema { * a high volume of writes and reads. The dataset access scope should be across * all servers that serve the application. * - * Note that the TTL of the data written to the store must be respected completely + * Note that the TTL of the data written to this store must be respected completely * before the data gets evicted from the store (whether the data is used or not). - * Thus, the store should not evict data before the TTL expires. + * The store must not evict data based on LRU or popularity before the TTL expires. * - * Properties of the backend should be: - * 1.) the data written to the store should be short-lived, - * 2.) it should be evicted ONLY after the TTL elapses (reliably persist), - * 3.) should be accessed by all servers that serve the application, - * 4.) should be able to handle a high volume of writes and reads. + * Expectations for sysadmins: + * + * 1. The data written to this store is generally short-lived (seconds/minutes), + * 2. This store must reliably persist and should not evict data until the TTL expires, + * 3. The same store must be accessed by all application servers (i.e. no visible lag or + * split reality), + * 4. This store should handle a high volume of both writes and reads, + * with reads completing with consistently low latencies. + * + * Examples users: + * + * - {@link MediaWiki::Permissions::RateLimiter RateLimiter} (via RStatsFactory) + * - {@link Wikimedia::Rdbms::ChronologyProtector ChronologyProtector} + * See also [ChronologyProtector requirements](@ref ChronologyProtector-storage-requirements), + * for more detailed system administrator requirements for multi-DC operations. + * + * Valid options are the keys of {@link $wgObjectCaches}, e.g. CACHE_* constants. * * @see \Wikimedia\ObjectCache\BagOStuff * @since 1.42 @@ -4156,26 +4168,6 @@ class MainConfigSchema { ], ]; - /** - * The object store type for the - * {@link Wikimedia::Rdbms::ChronologyProtector ChronologyProtector} store. - * - * This should be a fast storage system optimized for lightweight ephemeral data. - * Data stored should be readable by all application servers in the local datacenter. - * - * See [ChronologyProtector requirements](@ref ChronologyProtector-storage-requirements) - * for more detailed system administrator requirements (especially for multi-dc operations). - * - * Valid options are the keys of {@link $wgObjectCaches}, e.g. CACHE_* constants. - * Defaults to {@link $wgMainCacheType} (in ServiceWiring.php). - * - * @since 1.36 - */ - public const ChronologyProtectorStash = [ - 'default' => null, - 'type' => '?string', - ]; - /** * Secret string for HMAC hashing in ChronologyProtector [optional] * -- cgit v1.2.3