Details
Critical - P2 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:
BEFORE: [
|
{
|
"_id" : "test.user-x_MinKey",
|
"lastmod" : Timestamp(1, 1),
|
"lastmodEpoch" : ObjectId("57b1229178e732ea6489534f"),
|
"ns" : "test.user",
|
"min" : {
|
"x" : { "$minKey" : 1 }
|
},
|
"max" : {
|
"x" : 0
|
},
|
"shard" : "shard0000"
|
},
|
{
|
"_id" : "test.user-x_0.0",
|
"lastmod" : Timestamp(1, 2),
|
"lastmodEpoch" : ObjectId("57b1229178e732ea6489534f"),
|
"ns" : "test.user",
|
"min" : {
|
"x" : 0
|
},
|
"max" : {
|
"x" : { "$maxKey" : 1 }
|
},
|
"shard" : "shard0000"
|
}
|
]
|
The chunks after running the splitChunk command:
AFTER: [
|
{
|
"_id" : "test.user-x_MinKey",
|
"lastmod" : Timestamp(1, 3),
|
"lastmodEpoch" : ObjectId("57b11ede5ed71a434707b87e"),
|
"ns" : "test.user",
|
"min" : {
|
"x" : { "$minKey" : 1 }
|
},
|
"max" : {
|
"x" : 2
|
},
|
"shard" : "shard0000"
|
},
|
{
|
"_id" : "test.user-x_0.0",
|
"lastmod" : Timestamp(1, 2),
|
"lastmodEpoch" : ObjectId("57b11ede5ed71a434707b87e"),
|
"ns" : "test.user",
|
"min" : {
|
"x" : 0
|
},
|
"max" : {
|
"x" : { "$maxKey" : 1 }
|
},
|
"shard" : "shard0000"
|
},
|
{
|
"_id" : "test.user-x_2.0",
|
"lastmod" : Timestamp(1, 4),
|
"lastmodEpoch" : ObjectId("57b11ede5ed71a434707b87e"),
|
"ns" : "test.user",
|
"min" : {
|
"x" : 2
|
},
|
"max" : {
|
"x" : 0
|
},
|
"shard" : "shard0000"
|
}
|
]
|
jstest attached. It fails with:
assert: [2] != [3] are not equal : Split chunks failed, but the chunks were updated in the config database
|
doassert@src/mongo/shell/assert.js:15:14
|
assert.eq@src/mongo/shell/assert.js:51:5
|
@split_chunk_out_of_bound.js:36:1
|
2016-08-15T02:11:18.422+0000 E QUERY [thread1] Error: [2] != [3] are not equal : Split chunks failed, but the chunks were updated in the config database :
|
doassert@src/mongo/shell/assert.js:15:14
|
assert.eq@src/mongo/shell/assert.js:51:5
|
@split_chunk_out_of_bound.js:36:1
|
failed to load: split_chunk_out_of_bound.js
|
Also, for 3.3.11 the primary shard fasserts (SERVER-24569) after config.chunks has been modified:
d20000| 2016-08-15T12:01:53.514+1000 I - [conn1] Fatal assertion 40221 IllegalOperation: cannot split chunk [{ x: MinKey }, { x: 0.0 }) at key { x: 2.0 } at src/mongo/db/s/split_chunk_command.cpp 436
|
d20000| 2016-08-15T12:01:53.514+1000 I - [conn1]
|
d20000|
|
d20000| ***aborting after fassert() failure
|
d20000|
|
d20000|
|
d20000| 2016-08-15T12:01:53.523+1000 F - [conn1] Got signal: 6 (Abort trap: 6).
|
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).
Attachments
Issue Links
- is related to
-
SERVER-25630 Add validation of splitVector output
-
- Closed
-
- related to
-
SERVER-24569 Maintain the 'rangesToClean' and 'metadataInUse' sets on chunk migrations
-
- Closed
-