reshardCollection

Initialization Phase

During the initialization phase, the resharding coordinator determines the new data distribution for the sharded collection.

Clone Phase

During the clone phase:

• Each recipient shard creates a temporary, empty sharded collection with the same collection options as the donor sharded collection. This new collection is the target for where recipient shards write the new data. The recipient shards do not create any index except the _id index until the index phase.

• Each recipient shard clones collection data from the donor shard, including all documents that the recipient shard owns under the new shard key.

Index Phase

During the index phase, each recipient shard builds the necessary new indexes. These include all existing indexes on the sharded collection and an index compatible with the new shard key pattern if such an index doesn't already exist on the sharded collection.

Apply and Catch-up Phase

During the apply and catch-up phase:

• Each recipient shard begins applying oplog entries that were written to the the corresponding donor shard after the recipient cloned the data.

• When the estimate for the time remaining to complete the resharding operation is under two seconds, the donor shard blocks writes on the source collection.

Commit Phase

During the commit phase:

• The resharding coordinator waits for all shards to reach strict consistency, then commits the resharding operation.

• The resharding coordinator instructs each donor and recipient shard primary, independently, to rename the temporary sharded collection. The temporary collection becomes the new resharded collection.

• Each donor shard drops the old sharded collection.

Reshard a Collection

The following example reshards the sales.orders collection with the new shard key { order_id: 1 }:

db.adminCommand({
  reshardCollection: "sales.orders",
  key: { order_id: 1 }
})

Output:

{
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp(1, 1624887954),
    signature: {
      hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
      keyId: 0
    }
  },
  operationTime: Timestamp(1, 1624887947)
}

Redistribute Data to New Shards

Starting in MongoDB 8.0, you can reshard a collection on the same key, which can be used to redistribute data onto new shards.

After adding a shard to the cluster, you use the reshardCollection command with the forceRedistribution option to redistribute data across the cluster:

db.adminCommand({
    reshardCollection: "accounts.invoices",
    key: { store_id: "hashed" },
    forceRedistribution: true
})

Redistribute Data to Different Zones

Starting in MongoDB 8.0, you can use the reshardCollection command to move data into new zones without changing the shard key.

The following command redistributes data for the accounts.sales collection using the same shard key, moving data to the shards associated with zones zone04 and zone05:

db.adminCommand({
    reshardCollection: "accounts.sales",
    key: { region_id: "hashed" },
    forceRedistribution: true,
    zones: [
        {
            zone: "zone04",
            min: { region_id: MinKey() },
            max: { region_id: 10 }
        },
        {
            zone: "zone05",
            min: { region_id: 10 },
            max: { region_id: MaxKey() }
        }
    ]
})