[SERVER-25527] Send the version of the chunk being moved as part of the shard moveChunk and splitChunk commands Created: 10/Aug/16 Updated: 06/Jan/17 Resolved: 17/Aug/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.12 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Kaloian Manassiev |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Sharding 2016-08-29 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Currently, mongos sends the collection version as part of the shard's moveChunk/splitChunk requests and MongoD versions 3.2 and earlier check that the collection version matches in the beginning of the operation and then include it as part of the applyOps command that they issue against the config server. This check on the collection version effectively serializes all metadata operations for the same collection, even though they might be for different chunks. It seems much more reasonable to send the version of the chunks being modified instead of the entire collection's version. In addition, with parallel migrations available in 3.4 we can no longer use the collection version when committing the migration because it may change when multiple migrations commit at once. The road to deprecation of the collectionVersion field should be:
This requires changes on the config server and on the shard itself. NOTE: The mongos invocation of the mergeChunks command intentionally does not include either of these fields, because (a) it contains a [min, max) range of chunks to be merged and it is impractical to send version for entry from the range due to the unbounded nature of such information and (b) it is a rare enough and cheap enough operation that having it fail due to collectionVersion mismatch at applyOps time is an acceptable tradeoff. |
| Comments |
| Comment by Githook User [ 17/Aug/16 ] |
|
Author: {u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}Message: Currently this value is ignored by the shard and it will be used by a |