Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-25602

splitChunk command with out of bound splitKeys fails, but still updates the chunks

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical - P2
    • Resolution: Fixed
    • Affects Version/s: 3.0.12, 3.2.8, 3.3.11
    • Fix Version/s: 3.2.10, 3.3.12
    • Component/s: Sharding
    • Labels:
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Completed:
    • Backport Requested:
      v3.0

      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

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                13 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: