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).
- 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
-