Navigation

Clear jumbo Flag

On this page

If MongoDB cannot split a chunk that exceeds the specified chunk size, MongoDB labels the chunk as jumbo.

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

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

Procedures

Divisible Chunks

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

1

Connect to mongos.

Connect a mongo shell to a mongos.

2

Find the jumbo Chunk.

Run sh.status(true) to find the chunk labeled jumbo.

copy 
sh.status(true)

For example, the following output from sh.status(true) shows that chunk with shard key range { "x" : 2 } -->> { "x" : 4 } is jumbo.

copy 
--- 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)
3

Split the jumbo Chunk.

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

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

MongoDB removes the jumbo flag upon successful split of the chunk.

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 the preferred method to clear the flag is not applicable. In such cases, you can clear the flag using the following steps.

Starting in version 4.2.3 and 4.0.15, MongoDB provides the clearJumboFlag command to manually clear the jumbo flag.

Important

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

1

Connect to mongos.

Connect a mongo shell to a mongos.

2

Find the jumbo Chunk.

Run sh.status(true) to find the chunk labeled jumbo.

copy 
sh.status(true)

For example, the following output from sh.status(true) shows that chunk with shard key range { "x" : 2 } -->> { "x" : 3 } is jumbo.

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

Run the clearJumboFlag Command.

From the admin database, run the clearJumboFlag, passing in the namespace of the sharded collection and either:

  • the bounds of the jumbo chunk:

    copy 
    db.adminCommand( {
   clearJumboFlag: "test.foo",
   bounds: [{ "x" : 2 }, { "x" : 3 }]

})

  • the find document with a shard key and value contained in the jumbo chunk:

    copy 
    db.adminCommand( {
   clearJumboFlag: "test.foo",
   find: { "x" : 2 }
})

    Note

    If the collection uses a hashed shard key, do not use the find field with clearJumboFlag. For hashed shard keys, use the bounds field instead.

Important

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

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

1

Stop the balancer.

Disable the cluster balancer process temporarily, following the steps outlined in Disable the Balancer.

2

Create a backup of config database.

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

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

Connect to mongos.

Connect a mongo shell to a mongos.

4

Find the jumbo Chunk.

Run sh.status(true) to find the chunk labeled jumbo.

copy 
sh.status(true)

For example, the following output from sh.status(true) shows that chunk with shard key range { "x" : 2 } -->> { "x" : 3 } is jumbo.

copy 
--- 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)
5

Update chunks collection.

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

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

Clear the cached routing information.

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

Starting in MongoDB 4.0.6 (and 3.6.11),

You must flush the cache on the config server primary for the namespace. This notifies the balancer of the jumbo flag clearance.

Connect a mongo shell to the config server primary and run flushRouterConfig for the collection:

copy 
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 cache from the config servers.

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

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.