About this Task关于此任务
Resharding to the same shard key lets you use resharding as a data movement mechanism. This enables you to:重新分片到相同的分片键可以让你将重新分片作为一种数据移动机制。这使您能够:
Use the Reshard to Shard technique to shard a collection and distribute its data across all relevant shards使用Reshard to 分片技术对集合进行分片,并将其数据分布在所有相关分片上Add new shards faster更快地添加新分片Remove shards faster更快地删除分片Rewrite collections to reclaim disk space重写集合以回收磁盘空间
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步骤
Reshard the collection.重新整理集合。
Use the 使用reshardCollection command with the forceRedistribution option set to true to reshard the collection. The reshardCollection command has the following syntax:reshardCollection命令,并将forceRedistribution选项设置为true,以重新标记集合。reshardCollection命令的语法如下:
db.adminCommand(
{
reshardCollection: "<database>.<collection>",
key: { "<shardkey>" },
unique: <boolean>,
numInitialChunks: <integer>,
collation: { locale: "simple" },
zones: [
{
min: { "<document with same shape as shardkey>" },
max: { "<document with same shape as shardkey>" },
zone: <string> | null
},
],
forceRedistribution: <bool>
}
)
For example, this command reshards the 例如,此命令将info.productsInformation collection on its current shard key { product_SKU : 1 }:info.productsInformation集合重新排序到其当前分片键{ product_SKU : 1 }上:
db.adminCommand(
{
reshardCollection: "info.productsInformation",
key: { product_SKU : 1 },
forceRedistribution: true
}
)
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当新的重新标记操作开始时,它将返回-1when a new resharding operation starts.-1。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>,
...
},
...
]