Docs Home → MongoDB Manual

Clear jumbo Flag

On this page本页内容

If MongoDB cannot split a chunk that exceeds the specified range size, MongoDB labels the chunk as jumbo.如果MongoDB无法拆分超过指定范围大小的区块，MongoDB会将该区块标记为jumbo。

The following procedures outline the steps to manually clear the jumbo flag.以下过程概述了手动清除jumbo标志的步骤。

Procedures过程

Divisible Chunks可分割区块

The preferred manual way to clear the jumbo flag from a chunk is to attempt to split the chunk. 从块中清除jumbo标志的首选手动方法是尝试拆分块。If the chunk is divisible, MongoDB removes the flag upon successful split of the chunk.如果区块是可分割的，MongoDB会在成功分割区块时删除标志。

1

Connect to mongos.连接到mongos。

Connect mongosh to a mongos.将mongosh连接到mongos。

2

Find the jumbo Chunk.找到巨型Chunk。

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

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.

 --- 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.拆分jumbo块。

Use either sh.splitAt() or sh.splitFind() to split the jumbo chunk.使用sh.splitAt()或sh.splitFind()来拆分巨型块。

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

MongoDB removes the jumbo flag upon successful split of the chunk.MongoDB在成功分割区块时删除jumbo标志。

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. As such, you cannot split the chunk to clear the flag.在某些情况下，MongoDB无法分割不再是jumbo的区块，例如具有单个分片键值范围的区块。因此，您不能通过拆分区块来清除标志。

In such cases, you can either change the shard key so that the chunk can become divisible or manually clear the flag.在这种情况下，您可以更改分片键以使区块可以被分割，也可以手动清除标志。

Refine the Shard Key优化分片关键帧

Starting in 4.4, MongoDB provides the refineCollectionShardKey command. Using the refineCollectionShardKey command, you can refine a collection's shard key by adding a suffix field or fields to the existing key. By adding new field(s) to the shard key, indivisible jumbo chunks can become divisible.

1
Connect to mongos.

Connect mongosh to a mongos.

2
Find the jumbo Chunk.找到jumbo块。

Run sh.status(true) to find the chunk labeled jumbo.运行sh.status(true)以查找标记为jumbo的区块。

sh.status(true)

For example, the following output from sh.status(true) shows that for the sharded collection test.orders, both the chunk with shard key range { "status" : "A" } -->> { "status" : "D" } and the chunk with range { "status" : "D" } -->> { "status" : "P" } are jumbo.

 --- Sharding Status ---
   sharding version: {
     ...
   }
   shards:
     ...
   databases:
     ...
     test.orders
        shard key: { "status" : 1 }
        unique: false
        balancing: true
        chunks:
                shardA       2
                shardB       2
        { "status" : { "$minKey" : 1 } } -->> { "status" : "A" } on : shardB Timestamp(3, 0)
        { "status" : "A" } -->> { "status" : "D" } on : shardA Timestamp(5, 1) jumbo
        { "status" : "D" } -->> { "status" : "P" } on : shardA Timestamp(4, 2) jumbo
        { "status" : "P" } -->> { "status" : { "$maxKey" : 1 } } on : shardB Timestamp(5, 0)
3
Refine the Shard Key for test.orders Collection.

To address the low cardinality of the key status, refine the key for the test.orders collection. For example, add the order_id and customer_id fields as a suffix to the current shard key; i.e. the shard key will be { status: 1, order_id: 1, customer_id: 1 } after refinement.

  1. First, create the index to support the shard key { status: 1, order_id: 1, customer_id: 1 } if the index does not already exist.

    db.orders.createIndex( { status: 1, order_id: 1, customer_id: 1 } )

    For additional index considerations for refining the shard key, see Index Considerations.

  2. In the admin database, run the refineCollectionShardKey command to add the order_id and customer_id fields as a suffix to the existing key:

    db.adminCommand( {
       refineCollectionShardKey: "test.orders",
       key: { status: 1, order_id: 1, customer_id: 1 }
    } )

The refineCollectionShardKey command updates the chunk ranges and zone ranges to incorporate the new fields without modifying the range values of the existing key fields. That is, the refinement of the shard key does not immediately affect the distribution of chunks across shards or zones. Any future chunk splits or migration occur as part of the routine sharding operations.

Tip

After you refine the shard key, it may be that not all documents in the collection have the suffix field(s). 细化分片键后，可能不是集合中的所有文档都具有后缀字段。To populate the missing shard key field(s), see Missing Shard Key Fields.要填充缺失的分片键字段，请参阅缺失的分片键字段。

Before refining the shard key, ensure that all or most documents in the collection have the suffix fields, if possible, to avoid having to populate the field afterwards.在细化分片键之前，如果可能的话，请确保集合中的所有或大多数文档都有后缀字段，以避免以后必须填充字段。

Manually Clear the jumbo Flag for an Indivisible Chunk

You can manually clear the flag using the following steps.

Important

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 4.2.3 and laterMongoDB 4.2.2 and earlier

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 mongosh to a mongos.

2
Find the jumbo Chunk.

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

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:

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

    })

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

    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.

For MongoDB 4.2.2 and earlier (and 4.0.14 and earlier), you must manually clear the jumbo flag using the following procedure.

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:例如：

mongodump --db=config --port=<config server port> --out=<output file>
3
Connect to mongos.

Connect mongosh to a mongos.

4
Find the jumbo Chunk.

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

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)
5
Update chunks collection.

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

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 mongosh to the config server primary and run flushRouterConfig 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 cache from the config servers.
Tip

See also: 另请参阅：

refineCollectionShardKey