-
Type: Bug
-
Resolution: Fixed
-
Priority: Critical - P2
-
Affects Version/s: 7.0.0
-
Component/s: None
-
Cluster Scalability
-
Fully Compatible
-
ALL
-
v7.3, v7.2, v7.0
-
(copied to CRM)
-
124
-
4
PM-2290/SERVER-72489 made the configsvr start using the ShardServerCatalogCacheLoader (instead of the ConfigServerCatalogCacheLoader) to refresh its in-memory routing table cache. The ShardServerCatalogCacheLoader persists the cache on internal collections (config.cache.<nss>) – one internal collection for each actual collection.
Some processes on the configsvr, such as the balancer or the shardingIndexConsistencyCheker, periodically refresh and use the routing tables. On deployments with a huge number of collections this will caused increased resource usage, particularly WT data handles, which are only garbage-collected after 10 minutes of inactivity. This leads to increased memory usage. Given that configsvr instances are typically small sized, this may trigger OOM failures.
For this issue, don’t allow transitioning into embedded config server and we restore always using the ConfigServerCatalogCacheLoader in 7.0 and 7.3, but do not change 8.0.
This means disabling transitionFromDedicatedConfigServer/transitionToDedicatedConfigServer.
- causes
-
SERVER-88172 Config can be used as primary shard even in cluster with dedicated config server
- Closed
- is caused by
-
SERVER-72489 Decide if catalog shards need ShardServerCatalogCacheLoader
- Closed
- is related to
-
SERVER-84243 Dedicate a catalog cache and loader to the shard role
- In Progress