-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Sharding NYC
-
Fully Compatible
-
Sharding NYC 2023-08-21, Sharding NYC 2023-09-04, Cluster Scalability 2023-12-11
-
0
-
3
Currently, when a shard replica set is reconfigured to add or remove nodes, all mongoses monitoring that set will detect the change and each one will attempt to update the seed list for that set that is stored on the config servers. This means all the mongoses are racing to do the update, performing duplicate and unnecessary work and network traffic. Instead, the primary of the set being reconfigured should be the sole party responsible for updating the configuration stored on the config servers.
- causes
-
SERVER-93707 ShardRegistry::scheduleReplicaSetUpdateOnConfigServerIfNeeded can write an incorrect config version
- Closed
- related to
-
SERVER-92996 Missed incrementing _rsmIncrement in ShardRegistry for config shard replica set update
- Closed