-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
Fully Compatible
-
ALL
-
26
Consider the following scenario to transitionToDedicatedConfigServer.
1. config shard is marked to start draining
2. The last chunk is moved out from the config shard
3. The last orphan is cleaned up
4. Once all the chunks/orphans are cleaned, all the dbs are dropped.
5. Remove entry from (config.shards)
If a ddl operation(drop or rename) is received before step 5, we will send drop/rename to all shards which takes a critical section lock on all the shards. And if the ddl operation completes after step 5, we will leave a lingering lock on config server since the release is sent to all shard (config server isn't a shard anymore).
This ticket is to add a workaround fix where when the critical section is released for drop/rename - include configServer in all shards list.
Also, consider/evaluate other DDLs as time permits
- causes
-
SERVER-87831 Undo workaround done by SERVER-87137
- Closed
- is related to
-
SERVER-90151 Incorrect collection sharding metadata can be left on dedicated config server after concurrent dropCollection
- Closed
-
SERVER-56879 Make DDLs operations resilient to add/remove shard
- Closed
-
SERVER-86943 Make the transition between embeded <> dedicated config shard a balancer-only hint
- Backlog