[SERVER-26885] Possible to complete migration with transferMods buffer not fully drained Created: 02/Nov/16  Updated: 19/Nov/16  Resolved: 07/Nov/16

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.4.0-rc2
Fix Version/s: 3.4.0-rc3

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: Kaloian Manassiev
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2016-11-21
Participants:
Linked BF Score: 0

 Description   

Steps:

  1. Migration initiated.
  2. Migration cloneLocs phase complete.
  3. Destination finished cloning.
  4. New write comes in.
  5. New write passes shard version check inside the OpObserver hook.
  6. MigrationSourceManager::enterCriticalSection.
  7. Donor sends commit command to destination.
  8. Destination sends _transferMods and gets an empty response, so it is ready to cleanup and complete the destination side of the migration.
  9. Doc _id of write is stored in transferMods buffer.
  10. New write returns success.

I believe the problem is because when we enter the critical section, we take IS lock on the ns:

https://github.com/mongodb/mongo/blob/r3.4.0-rc2/src/mongo/db/s/migration_source_manager.cpp#L246

That means that it can run in parallel with the new write that came in since it is compatible with IX.



 Comments   
Comment by Githook User [ 07/Nov/16 ]

Author:

{u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}

Message: SERVER-26885 Take collection X lock to enter the migration critical section
Branch: master
https://github.com/mongodb/mongo/commit/10c5d764eec26b00947ae8e18cfddc5f8b3af629

Generated at Thu Feb 08 04:13:30 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.