Clear jumbo Flag

If MongoDB cannot split a chunk that exceeds the specified chunksize, MongoDB labels the chunk asjumbo.

If the chunk size no longer exceeds the specified chunk size, MongoDB clears the jumbo flag for the chunkwhen the mongos rewrites the chunk metadata.

In cases where you need to clear the flag manually, the followingprocedures outline the steps to manually clear the jumbo flag.

Procedures

Divisible Chunks

The preferred way to clear the jumbo flag from a chunk is toattempt to split the chunk. If the chunk is divisible, MongoDB removesthe flag upon successful split of the chunk.

Connect to mongos.

Connect a mongo shell to a mongos.

Find the jumbo Chunk.

Run sh.status(true) to find the chunk labeledjumbo.

sh.status(true)

For example, the following output from sh.status(true) shows thatchunk with shard key range { "x" : 2 } —>> { "x" : 4 } isjumbo.

--- Sharding Status ---
  sharding version: {
     ...
  }
  shards:
     ...
  databases:
     ...
        test.foo
           shard key: { "x" : 1 }
        chunks:
             shard-b  2
             shard-a  2
        { "x" : { "$minKey" : 1 } } -->> { "x" : 1 } on : shard-b Timestamp(2, 0)
        { "x" : 1 } -->> { "x" : 2 } on : shard-a Timestamp(3, 1)
        { "x" : 2 } -->> { "x" : 4 } on : shard-a Timestamp(2, 2) jumbo
        { "x" : 4 } -->> { "x" : { "$maxKey" : 1 } } on : shard-b Timestamp(3, 0)

Split the jumbo Chunk.

Use either sh.splitAt() or sh.splitFind() tosplit the jumbo chunk.

sh.splitAt( "test.foo", { x: 3 })

MongoDB removes the jumbo flag upon successful split of thechunk.

Indivisible Chunks

In some instances, MongoDB cannot split the no-longer jumbo chunk,such as a chunk with a range of single shard key value, and thepreferred method to clear the flag is not applicable. In such cases,you can clear the flag using the following steps.

Important

Only use this method if the preferred method is not applicable.

Before modifying the config database, always back up the config database.

If you clear the jumbo flag for a chunk that still exceeds thechunk size, MongoDB will re-label the chunk as jumbo when MongoDBtries to move the chunk.

Stop the balancer.

Disable the cluster balancer process temporarily, following the stepsoutlined in Disable the Balancer.

Create a backup of config database.

Use mongodump against a config server to create a backupof the config database. For example:

mongodump --db=config --port=<config server port> --out=<output file>

Connect to mongos.

Connect a mongo shell to a mongos.

Find the jumbo Chunk.

Run sh.status(true) to find the chunk labeledjumbo.

sh.status(true)

For example, the following output from sh.status(true) shows thatchunk with shard key range { "x" : 2 } —>> { "x" : 3 } isjumbo.

--- Sharding Status ---
  sharding version: {
     ...
  }
  shards:
     ...
  databases:
     ...
        test.foo
           shard key: { "x" : 1 }
        chunks:
             shard-b  2
             shard-a  2
        { "x" : { "$minKey" : 1 } } -->> { "x" : 1 } on : shard-b Timestamp(2, 0)
        { "x" : 1 } -->> { "x" : 2 } on : shard-a Timestamp(3, 1)
        { "x" : 2 } -->> { "x" : 3 } on : shard-a Timestamp(2, 2) jumbo
        { "x" : 3 } -->> { "x" : { "$maxKey" : 1 } } on : shard-b Timestamp(3, 0)

Update chunks collection.

In the chunks collection of the config database, unset thejumbo flag for the chunk. For example,

db.getSiblingDB("config").chunks.update(
   { ns: "test.foo", min: { x: 2 }, jumbo: true },
   { $unset: { jumbo: "" } }
)

Clear the cached routing information.

After the jumbo flag has been cleared out from the chunkscollection, update the cluster routing metadata cache.

Starting in MongoDB 4.0.6 (and 3.6.11), you must flush the cache onthe config server primary for the namespace. This notifies thebalancer of the jumbo flag clearance.

In earlier versions (MongoDB 3.4-series, MongoDB 3.6.0-3.6.10,MongoDB 4.0.0-4.0.5), you must step down the config server primary.

• Starting in MongoDB 4.0.6 (and 3.6.11)
• Connect amongo shell to the config server primary and runflushRouterConfig for the collection:

db.adminCommand( { flushRouterConfig:  "test.foo" } )

• In earlier versions (MongoDB 3.4-series, MongoDB 3.6.0-3.6.10, MongoDB 4.0.0-4.0.5)
• Step down the config server primary to clear the routing metadata cachefrom the config servers.