About this Task关于此任务
You can use resharding to distribute your sharded collections to new shards. You can also use it to remove shards faster than chunk migrations.您可以使用重新分片将分片集合分发到新的分片。您还可以使用它比块迁移更快地删除分片。
The resharding operation performs these phases in order:换牌操作按顺序执行以下阶段:
The clone phase duplicates the current collection data.克隆阶段复制当前集合数据。The building indexes phase builds indexes on the resharded collection.构建索引阶段在重新托管的集合上构建索引。The catch-up phase applies any pending write operations to the resharded collection.追赶阶段将所有挂起的写入操作应用于重新托管的集合。The commit phase renames the temporary collection and drops the old collection to perform a cut-over.提交阶段重命名临时集合并删除旧集合以执行切换。
Before you Begin开始之前
Before you reshard, you must calculate your cluster's Storage Requirements, Latency Requirements, and any Additional Resource Requirements.在重新挂卡之前,您必须计算集群的存储要求、延迟要求和任何其他资源要求。
Storage Requirements存储需求
Calculate the required storage space for the resharding operation by adding your collection size and index size, assuming a minimum oplog window of 24 hours by using this formula:通过将集合大小和索引大小相加来计算重新标记操作所需的存储空间,假设最小oplog窗口为24小时,使用以下公式:
Available storage required on each shard = [(collection size + index size) *2 ] / number of shards the collection will be distributed across.
For example, a 2TB collection and 400GB of indexes distributed across 4 shards will need a minimum of 1.2TB of available storage per shard:例如,分布在4个分片上的2TB集合和400GB索引,每个分片至少需要1.2TB的可用存储空间:
[ (2 TB + 400GB) * 2 ] / 4 shards = 1.2 TB / shard
You must confirm that you have the available storage space in your cluster.您必须确认群集中有可用的存储空间。
If there is insufficient space or I/O headroom available, you must increase the storage size. If there is insufficient CPU headroom, you must scale up the cluster by selecting a higher instance size.如果可用空间或I/O净空不足,则必须增加存储大小。如果CPU空间不足,则必须通过选择更大的实例大小来扩展集群。
Tip
If your MongoDB cluster is hosted on Atlas, you can use the Atlas UI to review storage, CPU, and I/O headroom metrics.如果MongoDB集群托管在Atlas上,你可以使用Atlas UI查看存储、CPU和I/O净空指标。
Latency Requirements延迟要求
You must ensure that your application can tolerate two seconds where the collection being resharded blocks writes. When writes are blocked, your application experiences an increase in latency. 您必须确保应用程序可以容忍两秒钟内被重新保护的集合块写入。当写入被阻止时,应用程序的延迟会增加。If your workload cannot tolerate this requirement, use chunk migrations to balance your cluster.如果工作负载无法满足此要求,请使用块迁移来平衡集群。
Additional Resource Requirements额外资源要求
Your cluster must meet these additional requirements:集群必须满足以下附加要求:
A minimum oplog window of 24 hours.最少24小时的oplog窗口。I/O capacity below 50%.I/O容量低于50%。CPU load below 80%.CPU负载低于80%。
Steps步骤
Add or remove shards to your cluster.在集群中添加或删除分片。
To add shards to your cluster, see Add Shards to a Cluster. 要向集群添加分片,请参阅向集群添加分片。To remove shards from your cluster, see Remove Shards from a Sharded Cluster.要从集群中删除分片,请参阅从分片集群中删除分片。
Reshard sharded collections one at a time to the same shard key.将已分片的集合一次一个地重新格式化到同一个分片键。
Use the 使用带有reshardCollection command with the forceRedistribution option to redistribute data across the cluster.forceRedistribution选项的reshardCollection命令在群集中重新分发数据。
db.adminCommand(
{
reshardCollection: "<db>.<collection>",
key: { "<shardkey>" },
forceRedistribution: true
}
)
Resharding with 使用forceRedistribution: true rewrites the data across all shards in the cluster that are not in a draining state. forceRedistribution:true重写集群中未处于耗尽状态的所有分片上的数据。By default, resharding uses 默认情况下,重新标记使用numInitialChunks: 90. Resharding creates at least numInitialChunks - 1 chunks in a cluster. numInitialChunks: 90。重新硬装在集群中至少创建numInitialChunks - 1个块。If you have more than 90 shards, specify a higher number of 如果有90个以上的分片,请在numInitialChunks in the reshardCollection command.reshardCollection命令中指定更多的numInitialChunks。
Note
Starting in MongoDB 8.2, resharding operations ignore the 从MongoDB 8.2开始,当分片键包含哈希前缀时,重新标记操作会忽略numInitialChunks setting when the shard key contains a hashed prefix. numInitialChunks设置。Instead, MongoDB deterministically splits the hashed key space among recipients, using the same approach as initial chunk creation for empty hashed collections.相反,MongoDB使用与空哈希集合的初始块创建相同的方法,在接收者之间确定性地分割哈希键空间。
Monitor the resharding operation.监控换牌操作。
To monitor the resharding operation, you can use the 要监视重新标记操作,可以使用$currentOp pipeline stage:$currentOp管道阶段:
db.getSiblingDB("admin").aggregate(
[
{ $currentOp: { allUsers: true, localOps: false } },
{
$match: {
type: "op",
"originatingCommand.reshardCollection": "<database>.<collection>"
}
}
]
)
Note
To see updated values, you need to continuously run the pipeline.要查看更新的值,您需要连续运行管道。
The $currentOp pipeline outputs:$currentOp管道输出:
totalOperationTimeElapsedSecs: elapsed operation time in seconds:运行时间(秒)remainingOperationTimeEstimatedSecs: estimated time remaining in seconds for the current resharding operation. It is returned as:当前重新分片操作的估计剩余时间(秒)。当新的重新标记操作开始时,它将返回-1。-1when a new resharding operation starts.Starting in MongoDB 7.0,从MongoDB 7.0开始,在重新标记操作期间,协调器上也可以使用remainingOperationTimeEstimatedSecsis also available on the coordinator during a resharding operation.remainingOperationTimeEstimatedSecs。remainingOperationTimeEstimatedSecsis set to a pessimistic time estimate:设置为悲观时间估计:The catch-up phase time estimate is set to the clone phase time, which is a relatively long time.追赶阶段时间估计值被设置为克隆阶段时间,这是一个相对较长的时间。In practice, if there are only a few pending write operations, the actual catch-up phase time is relatively short.在实践中,如果只有少数未决的写入操作,则实际的追赶阶段时间相对较短。
[
{
shard: '<shard>',
type: 'op',
desc: 'ReshardingRecipientService | ReshardingDonorService | ReshardingCoordinatorService <reshardingUUID>',
op: 'command',
ns: '<database>.<collection>',
originatingCommand: {
reshardCollection: '<database>.<collection>',
key: <shardkey>,
unique: <boolean>,
collation: { locale: 'simple' }
},
totalOperationTimeElapsedSecs: <number>,
remainingOperationTimeEstimatedSecs: <number>,
...
},
...
]
Resharding with 使用forceRedistribution: true rewrites the collection data to all the relevant shards and drops the old collection. It is the fastest method to move data in a cluster.forceRedistribution:true将集合数据重写到所有相关分片,并删除旧集合。这是在集群中移动数据最快的方法。