-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Catalog and Routing
-
Fully Compatible
-
ALL
-
CAR Team 2026-09-14
-
0
-
🟩 Routing and Topology
-
None
-
None
-
None
-
None
-
None
-
None
This issue is very similar to SERVER-96906 except that the drop of the collections does not come from the removeShard operation but rather from the shard being cleaned up prior to being decommissioned.
The add_remove_shards.py hook deletes the user databases on the shard prior to shutting it down. These drops are done via direct shard connection and therefore do not acquire the DDL lock or critical section and so do not serialize with any cluster level DDLs.
If a CMC command starts before a shard has updated its shard registry and still targets this shard, then it can see the result of the dropDatabases which can result in failures or false positive inconsistencies.
- is caused by
-
SERVER-102818 Add a test suite that does add/remove shard in the background
-
- Closed
-
- is related to
-
SERVER-96906 Collection can unexpectedly disappear while holding database DDL lock during checkMetadataConsistency()
-
- Closed
-
- related to
-
SERVER-134524 The ContinuousAddRemoveShard validation the shard is empty on decommission always succeeds due to broken iteration code
-
- Needs Scheduling
-