[SERVER-25602] splitChunk command with out of bound splitKeys fails, but still updates the chunks Created: 15/Aug/16 Updated: 05/Mar/18 Resolved: 16/Aug/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.0.12, 3.2.8, 3.3.11 |
| Fix Version/s: | 3.2.10, 3.3.12 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Linda Qin | Assignee: | Kaloian Manassiev |
| Resolution: | Done | Votes: | 0 |
| Labels: | bkp, code-and-test | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Completed: | |||||||||||||||||
| Backport Requested: |
v3.0
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Run the splitChunk command with out of bound splitKeys, the command fails. But it still updates the chunks, hence results in corrupted config database with overlap chunks and a chunk with reverse order. We've tested 3.0.12, 3.2.8, 3.2.9-rc1, 3.3.10 and 3.3.11. All have the same issue. The chunks before running the splitChunk command:
The chunks after running the splitChunk command:
jstest attached. It fails with:
Also, for 3.3.11 the primary shard fasserts (
fassert is not an apporpriate response to the server receiving a command with bad parameters. The command should just fail and return an error (with no side effects). |
| 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: |
| Comment by Githook User [ 16/Aug/16 ] |
|
Author: {u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}Message: |
| Comment by Kaloian Manassiev [ 15/Aug/16 ] |
|
Presently, the shards (mongod) do not validate the input of the splitChunk command, and in particular do not check that the split points fall within the range of the chunk. This is because the splitChunk, which is an internal administrative command, assumes that its only caller is mongos. The issue described in this ticket can only happen in two cases:
We are going to use this ticket to tighten the checks which the shards perform in order to ensure that incorrect metadata is never written in a case like this, and produce an error message instead. Please continue to watch the ticket for updates. Best regards, |
| Comment by Adam Flynn [ 15/Aug/16 ] |
|
Thanks for the quick turnaround on this. It caused serious production issues for us (essentially lost read availability on a very large collection for 2 days). I know timing's tight, but we'd really appreciate if this fix ships with 3.2.9. |