-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
None
-
Catalog and Routing
-
ALL
-
Sharding 2018-07-02, Sharding 2018-07-16, Sharding 2018-07-30, Sharding 2018-08-13, Sharding 2018-09-24, Sharding 2018-11-05, Sharding 2018-11-19, Sharding 2018-12-03, Sharding 2018-12-17, Sharding 2018-12-31, Sharding 2019-01-14
-
20
If a thread doing removeShard on the config server calls shardRegistry->getShard() in order to check for the existence of a shard, it may not see that the shard has already been removed by another thread. If instead of getShard() we perform a local read + wait for majority write concern, if a concurrent remove is happening but not yet replicated, we will correctly error out. Repro is attached for test configsvr_metadata_commands_require_majority_write_concern.js.
- is related to
-
SERVER-33797 sharding metadata command should make sure that ShardRegistry is up to date
- Closed
- related to
-
SERVER-48201 ShardRegistry::reload() competes with updates to the ShardRegistry through the RSM
- Closed