Starting in MongoDB 8.0, you can reshard to the same shard key to move data with no downtime or impact on workload. This enables you to:从MongoDB 8.0开始，您可以重新标记到相同的分片键来移动数据，而不会停机或影响工作负载。这使您能够：
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重写集合以回收磁盘空间
Starting in MongoDB 8.0, resharding reads data using natural order scan. Resharding first clones all the data and then builds relevant indexes, resulting in orders of magnitude speed improvement of the resharding process.从MongoDB 8.0开始，重新标记使用自然顺序扫描读取数据。重新装帧首先克隆所有数据，然后构建相关索引，从而使重新装帧过程的速度提高了几个数量级。
Command Syntax命令语法
You can reshard to the same key using the 您可以在reshardCollection command with forceRedistribution set to true.forceRedistribution设置为true的情况下使用reshardCollection命令将卡片重新粘贴到同一键。
The reshardCollection command has the following syntax: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>
}
)Note
Starting in MongoDB 8.2, resharding operations ignore the 从MongoDB 8.2开始，当分片键包含哈希前缀时，重新标记操作会忽略numInitialChunks setting when the shard key contains a hashed prefix. Instead, MongoDB deterministically splits the hashed key space among recipients, using the same approach as initial chunk creation for empty hashed collections.numInitialChunks设置。相反，MongoDB使用与空哈希集合的初始块创建相同的方法，在接收者之间确定性地分割哈希键空间。
For details, see 有关详细信息，请参阅reshardCollection.reshardCollection。
Use Cases用例
Resharding is a strategy to move data with no downtime or impact on workload. Use the Reshard to Shard technique to shard a collection and distribute data across all shards.重新分片是一种在不停机或不影响工作负载的情况下移动数据的策略。使用Reshard to 分片技术对集合进行分片，并在所有分片之间分发数据。
Use resharding to distribute your collections across all relevant shards faster than chunk migrations. 使用重新分级可以比块迁移更快地在所有相关分片上分发集合。Resharding writes to all shards in parallel while each shard can only participate in one chunk migration at a time. Resharding drops the old collection at the end of the process. Resharding并行写入所有分片，而每个分片一次只能参与一个块迁移。Resharding会在流程结束时删除旧集合。There are no orphan documents at the end of resharding.换牌结束时没有孤立文档。
Reshard to Shard从Reshard到分片
The Reshard to Shard technique lets you use resharding to shard a collection and distribute the data to all of the shards in a cluster.Reshard to 分片技术允许您使用resharding对集合进行分片，并将数据分发到集群中的所有分片。
Consider using Reshard to Shard when you are initially sharding a collection of any size across any number of shards. 当您最初在任意数量的分片上分片任何大小的集合时，请考虑使用Reshard to 分片。If your deployment meets the resource requirements, use Reshard to Shard no matter how large the collection you want to shard.如果部署满足资源要求，无论你想分片多大的集合，都可以使用Reshard to 分片。
Behavior行为
Storage存储
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 / shardYou 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延迟
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%。