Several DDL coordinators are executing operations on multiple shards by retrieving their list from the shard registry when needed, often assuming the set of shards to be stable during the whole duration of the DDL.
As a consequence, when shards are added/removed while DDLs are ongoing may result in partially executing metadata changes on some shards (in the best cases) and potentially in causing coordinators to get stuck (in the worse cases).
Purpose of this ticket is to provide a novel synchronization/serialization mechanism between DDLs and add/remove shard so that they can be executed concurrently with no side effects.
- causes
-
SERVER-91475 Make the _shardsvrJoinDDLCoordinators command resilient to FailedToSatisfyReadPreference exception
- Closed
- fixes
-
SERVER-90291 Resharding can race with transitionToDedicatedConfigsvr to recreate databases on config shard
- Closed
- has to be done before
-
SERVER-87831 Undo workaround done by SERVER-87137
- Closed
- is depended on by
-
SERVER-90224 Run sharding metadata consistency checks after ContinuousConfigShardTransition hook completes a transition
- Closed
- is duplicated by
-
SERVER-90629 moveCollection is allowed to run after a shard has finished draining resulting in data on a rs that is no longer a shard
- Closed
- related to
-
SERVER-86015 ShardCollection should not create chunks on a draining shard
- Closed
-
SERVER-87137 Support drop/rename collection DDL ops with transitionToDedicatedConfigServer
- Closed
-
SERVER-90151 Incorrect collection sharding metadata can be left on dedicated config server after concurrent dropCollection
- Closed
-
SERVER-89841 Investigate DDL LockBusy errors in config transition suite tests
- Closed
-
SERVER-90786 SERVER-90786 execute again tests excluded due to add/remove shard issue solved by SERVER-56879
- Closed