从MongoDB 8.0 开始，您可以重新分片到相同的分片键以移动数据，而无需停机或影响工作负载。这使您能够：
使用重新分片到分片技术对集合分片，并将其数据分布到所有相关分片
更快地添加新分片
更快地删除分片
重写集合以回收磁盘空间
从MongoDB 8.0 开始，重新分片使用自然顺序扫描读取数据。重新分片首先克隆所有数据，然后构建相关索引，从而将重新分片进程的速度提高几个数量级。
命令语法
您可以使用 reshardCollection 命令并将 forceRedistribution设立为 true 来重新分片为相同的键。
reshardCollection 命令具有以下语法：
db.adminCommand( { reshardCollection: "<database>.<collection>", key: { "<shardkey>" }, unique: <boolean>, numInitialChunks: <integer>, numSamplesPerChunk: <integer>, // New in MongoDB 8.0.20 collation: { locale: "simple" }, zones: [ { min: { "<document with same shape as shardkey>" }, max: { "<document with same shape as shardkey>" }, zone: <string> | null }, ], forceRedistribution: <bool> } )
注意
当分片键包含哈希前缀时，重新分片操作会忽略 numInitialChunks 设置。相反， MongoDB使用与为空哈希集合创建初始数据块相同的方法，确定性地在接收者之间分割哈希键空间。
有关详细信息，请参阅reshardCollection。
用例
重新分片是一种在不停机或影响工作负载的情况下移动数据的策略。使用重新分片到分片技术对集合分片并在所有分片之间分发数据。
使用重新分片可以比数据块迁移更快地将集合分发到所有相关分片。重新分片会并行写入所有分片，而每个分片一次只能参与一个数据块迁移。重新分片会在进程结束时删除旧集合。重新分片结束时不存在孤立文档。
重新分片到分片
重新分片到分片技术允许您使用重新分片对集合分片，并将数据分发到集群中的所有分片。
Consider using Reshard to Shard when you are initially sharding a collection of any size across any number of shards. If your deployment meets the resource requirements, use Reshard to Shard no matter how large the collection you want to shard.
行为
存储
假设最小oplog window为 24 小时，通过将集合大小和索引大小相加，使用以下公式计算重新分片操作所需的存储空间：
Available storage required on each shard = [(collection size + index size) *2 ] / number of shards the collection will be distributed across.
示例，一个 2TB 的集合和分布式在 4 个分片上的 400 GB的索引，每个分片至少需要 1.2TB 的可用存储：
[ (2 TB + 400GB) * 2 ] / 4 shards = 1.2 TB / shard
您必须确认集群中有可用的存储空间。
如果可用空间或 I/O 空间不足，则必须增加存储大小。如果 CPU 空间不足，则必须选择更大的实例大小来扩展集群。
提示
如果您的MongoDB 集群托管在Atlas上，则可以使用Atlas用户界面查看存储、CPU 和 I/O 空间指标。
延迟
您必须确保应用程序可以容忍正在重新分片的集合阻塞写入的两秒钟时间。当写入受阻时，应用程序的延迟会增加。如果您的工作负载无法容忍此要求，请使用数据块迁移来平衡集群。
重新分片限制
如果集合使用Atlas Search，则在操作完成后，搜索索引将变为不可用。要恢复索引，请手动重建搜索索引。
不支持使用可查询加密的集合。
其他资源要求
您的集群必须满足这些额外要求：
最小oplog window为 24 小时。
I/O容量低于 50%。
CPU 负载低于 80%。