-
Type: Bug
-
Resolution: Works as Designed
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.6.0-rc1
-
Component/s: Sharding
-
None
-
Sharding
-
ALL
Recipient shards take the DBLock twice, during the first two steps in the MigrationDestinationManager:
Step 0 ("copy system.namespaces entry if collection doesn't already exist"): takes the DBLock in mode IX if it has the collection, else in mode X so the collection can be created
Step 1 ("copy indexes"): takes the DBLock in mode X
It may be unnecessarily heavy-handed to take the DBLock in mode X in Step 1 (although, createIndexes command itself does take the DBLock in mode X in case it needs to create the collection, but only relocks it with mode IX if the index was asked to be built in the background. createIndexes does relock the DBLock in mode X regardless to complete the index build).
Note that SERVER-31485 will make the MigrationDestinationManager hold the DBLock across both steps.
- is related to
-
SERVER-31485 Race between move chunks and dropIndex may lead to IndexNotFound error
- Closed