-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: 3.1.7
-
Component/s: Sharding
-
Fully Compatible
-
ALL
-
Sharding F (01/29/16), Sharding 10 (02/19/16)
The donor does not tell the recipient to abort the migration when it returns early in some cases. Some of them are fine as they are a result of the recipient shard aborting. To make things worse, the _migrateClone and _transferMods doesn't include any parameter indicating what they are requesting, so it seems possible for these command to be pulling data intended for a different migration session. For example, if the donor shard aborts without informing the recipient and then starts donating chunk to another shard.
The donor restarting would most likely not exhibit this issue as the recipient shard is using the same connection to talk to the donor for the entire migration.
One example of the donor shard aborting is through the killOp interruption points.
- is duplicated by
-
SERVER-16540 Potential race in migration can have an aborted migration consume MigrateStatus::_cloneLocs
- Closed
- is related to
-
SERVER-22351 Write tests for migration session ID
- Closed
-
SERVER-22459 Write multiversion test for migration session ID, in v3.2
- Closed
- related to
-
SERVER-22498 Fix migration session id multiversion failure
- Closed