-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
Sharding 2020-05-18, Sharding 2020-06-01
Optimize ScopedShardVersionCriticalSection class with respect to multi-thread initialization. In particular in the case where a lot of threads try to concurrently instantiate this object.
The idea is to avoid entering in the critical session if it is not strictly needed.
Modify onShardVersionMismatch in order to:
- Wait on an ongoing shard version refresh or trigger it with a forceShardFilteringMetadataRefresh call
Update forceShardFilteringMetadataRefresh:
- Remove forceRefreshFromThisThread flag
- Remove unused hasAdditionalCatalogCacheForFiltering part
- causes
-
SERVER-48487 Use DBLock instead of AutoGetDB in onShardVersionMismatch
- Closed
- depends on
-
SERVER-47974 Introduce ScopedShardVersionCriticalSection class
- Closed
- is depended on by
-
SERVER-45983 Perform the shardVersion recovery and refresh on a separate thread from that of the user request
- Closed
-
SERVER-47982 Change the shard version update procedure of the migration source manager
- Closed
-
SERVER-47985 Implement recovery of a shard's `shardVersion` before it is allowed to perform version checking
- Closed
- is duplicated by
-
SERVER-48180 Make onShardVersionMismatch use ScopedShardVersionCriticalSection
- Closed