The chunk migration logic on the recipient side unconditionally acquires database X-lock acquisition at migration start in order to copy the collection indexes and options from the donor.
Similarly to the donor side, this lock acquisition can block behind active transactions and lead to stalls. However, what makes them worse than the donor is that while these lock requests are waiting to be granted, the recipient is not making any progress cloning the chunk. This in turn has the potential to cause buildup of xferMods on the donor side, leading to high memory utilization and/or increased duration of the migration.
Because of this, the MigrationDestinationManager should first use AutoGetCollection with MODE_IX lock to check whether the collection exists and only if it doesn't exist should it resort to MODE_X database lock.
- is related to
-
SERVER-86727 Consider changing MigrationDestinationManager::cloneCollectionIndexesAndOptions to not take DB MODE_X lock
- Closed