-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
ALL
-
Sharding 10 (02/19/16), Sharding 11 (03/11/16)
-
0
If the applyChunkOpsDeprecated's applyOps write works, but doesn't send back OK, it will retry. However, because the first write worked, the precondition does not match and it returns an error. applyChunkOpsDeprecated should double check whether the chunk changes did actually make it into the oplog, and if so return success.
moveChunk already deals with this issue, but splitChunk and mergeChunk do not. ChunkMoveOperationState::commitMigration looks at the result of applyChunkOpsDeprecated and if there's an error reloads the chunk information from the oplog and checks to see if the new version number is there – if so, it succeeded.
Potential solution:
add a parameter (ChunkType?) to applyChunkOpsDeprecated that holds the last chunk and chunk version of the ops being applied by applyOps. Move the applyOpsStatus logic in ChunkMoveOperationState::commitMigration into applyChunkOpsDeprecated and generalize it to handle move/split/merge versioning checks.
- is related to
-
SERVER-22849 Shard registry should update config last visible opTime even on command errors
- Closed