Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
3.4.6, 3.5.10
-
Fully Compatible
-
ALL
-
v3.4
-
Sharding 2017-08-21
Description
moveChunk's are considered equal even if their 'waitForDelete' options do not match:
https://github.com/mongodb/mongo/blob/r3.5.10/src/mongo/s/move_chunk_request.cpp#L159-L170
bool MoveChunkRequest::operator==(const MoveChunkRequest& other) const {
|
if (_nss != other._nss)
|
return false;
|
if (_fromShardId != other._fromShardId)
|
return false;
|
if (_toShardId != other._toShardId)
|
return false;
|
if (_range != other._range)
|
return false;
|
|
return true;
|
}
|
However, only the active moveChunk acts on its 'waitForDelete' option.
So, if the active moveChunk has waitForDelete=false, a moveChunk that joins it will exhibit waitForDelete=false behavior even if it has waitForDelete=true.
A quick fix for this is to include the 'waitForDelete' option when comparing moveChunk requests. This way, if a later moveChunk's waitForDelete does not match the active moveChunk's waitForDelete, the later moveChunk will fail with ConflictingOperationInProgress rather than succeeding silently.
A longer fix is to refactor the schedule range deletion and waitForDelete behavior so that it is done by each moveChunk request according to its own waitForDelete option. This would allow a later moveChunk to join the active one for the actual migration, but wait for delete independently.
Attachments
Issue Links
- is related to
-
SERVER-29834 only the active moveChunk on a shard will set the last opTime to wait for writeConcern for
-
- Closed
-
- related to
-
SERVER-43441 Remove TODO listed in SERVER-30183
-
- Closed
-