sh.reshardCollection()

Initialization Phase

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

Index Phase

During the index phase:

• Each shard recipient creates a new, empty sharded collection with the same collection options as the existing sharded collection. This new sharded collection is the target for where recipient shards write the new data.

• Each shard recipient 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.

Clone, Apply, and Catch-up Phase

During the clone, apply, and catch-up phase:

• Each shard recipient clones an initial copy of the documents it would own under the new shard key.

• Each shard recipient begins applying oplog entries from operations that happened after the recipient cloned the data.

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

  Note

  If required, you can manually force the resharding operation to complete by issuing the sh.commitReshardCollection() method. This is useful if the current time estimate to complete the resharding operation is an acceptable duration for your collection to block writes. The sh.commitReshardCollection() method blocks writes early and forces the resharding operation to complete. During the time period where writes are blocked your application experiences an increase in latency.

Commit Phase

• After the resharding process reaches the commit phase, the process cannot be ended with sh.abortReshardCollection().

• When all shards have reached strict consistency, the resharding coordinator commits the resharding operation and installs the new routing table.

• 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.

  Tip

  See also:

  Reshard a Collection

Reshard a Collection

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

sh.reshardCollection( "sales.orders", { order_id: 1 } )

Example output:

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

Reshard a Collection with Zones

Reshard a collection with zones when you need to adjust the distribution of data across the shards in your cluster to meet changing requirements or to improve performance.

In the following example, the test.scores collection resides on shard0 and shard1. The current shard key is { _id: 1}.

sh.addShardToZone( “shard2”, ‘NewZone’ )
sh.addShardToZone( “shard3”, ‘NewZone’ )

sh.reshardCollection(
  "test.scores",
  { "studentId": 1, "testId": 1},
  { zones: [ {
    min: { "studentId": MinKey(), "testId": MinKey() },
    max: { "studentId": MaxKey(), "testId": MaxKey() },
    zone: "NewZone" }
    ]
} )

{
   ok: 1,
   '$clusterTime': {
   clusterTime: Timestamp( { t: 1699484530, i: 54 } ),
   signature: {
   hash: Binary.createFromBase64( "90ApBDrSSi4XnCpV3OWIH4OGO0Y=", 0 ),
   keyId: Long( "7296989036055363606" )
   } },
   operationTime: Timestamp( { t: 1699484530, i: 54 } )
}