mongodb 8.0 支持嵌入式配置服务器、跨区域movecollection、异步chunk清理及相同分片键reshardcollection，但需fcv设为8.0且仅限新集群或范围分片键。
8.0 中配置服务器不再需要独立部署
MongoDB 8.0 移除了对专用 config server replica set (CSRS) 的强制要求。此前版本必须用三个节点组成独立副本集存放集群元数据；8.0 允许将配置服务器功能嵌入到普通分片副本集中——即“嵌入式分片配置服务器”。这意味着你可以用更少的节点数启动分片集群，尤其适合开发或轻量级生产环境。
但注意：该模式仅适用于新初始化的集群。已存在的 CSRS 无法直接降级为嵌入式；升级现有集群时，mongod 进程仍会沿用原有 CSRS 架构，不会自动迁移或合并配置数据。
- 新集群启用嵌入式配置需在启动
mongod时显式指定--configsvr并加入分片副本集（而非单独部署） - 嵌入式配置下，
mongos仍连接同一地址列表，但元数据读写路径内部重定向 - 不建议在高负载、多租户生产环境中混用嵌入式与传统 CSRS，元数据一致性模型未开放切换开关
moveCollection 在 8.0 中支持跨区域迁移
sh.moveCollection() 命令在 8.0 中扩展了能力：它现在能尊重并强制遵守 zones 配置，允许你把未分片集合从一个地理区域（如 "us-east"）整体迁移到另一个（如 "eu-west"），而此前版本只支持在无 zone 约束下的分片间移动。
这个变化直接影响多区域多租户架构——比如 SaaS 应用按客户所在大区隔离数据，现在可直接用一条命令完成租户级集合搬迁，无需停服或导出导入。
- 迁移前必须确保目标分片已绑定对应 zone，且
minKey/maxKey范围覆盖该集合全键空间 - 执行期间该集合不可写（类似早期版本），但读操作仍被路由到原分片直到迁移完成
- 失败后不会自动回滚，需手动调用
sh.removeShard()清理残留状态（如果有的话）
负载均衡器默认启用异步范围清理
8.0 的负载均衡器在完成一次 chunk 迁移后，不再同步等待源分片彻底删除旧数据副本。它改用后台线程异步清理，降低迁移过程中的锁竞争和主从延迟波动。
这个改动让 balancer 更适应突发写入场景——例如某分片正承受大量插入，此时触发均衡，旧 chunk 数据不会阻塞新写入落盘。
- 清理延迟通常在几秒内，可通过
sh.setBalancerState(true)后观察sh.status()中balancing字段确认是否活跃 - 异步清理不影响
sh.stopBalancer()行为：停止后所有迁移及清理都会暂停 - 若发现某分片磁盘空间持续不释放，检查
db.adminCommand({getCmdLineOpts:1})是否启用了--disableChunkMigrationCleanup（极少数调试场景才设）
reshardCollection 支持相同分片键重分布
8.0 允许对已分片集合执行 db.runCommand({ reshardCollection: "db.coll", key: { shardKey: 1 } })，即使新旧分片键完全一致。这不再是无效操作，而是触发“重新分布”流程：MongoDB 会根据当前分片数量和 chunk 分布，重新计算并迁移 chunk，使数据更均匀——尤其适合新增分片后快速填平负载差异。
相比传统 moveChunk 手动调优，这是唯一能在不停写前提下优化热点分片的内置机制。
- 必须确保
featureCompatibilityVersion已设为"8.0"，否则命令返回错误InvalidOptions: reshardCollection requires fcv 8.0 - 执行期间集合仍可读写，但写入吞吐可能下降 10–20%，取决于 chunk 数量和网络延迟
- 不能用于哈希分片键，仅支持范围分片键（包括复合键）
featureCompatibilityVersion 升级顺序：必须先在所有节点上执行 db.adminCommand({setFeatureCompatibilityVersion: "8.0"})，再重启 mongos 和分片节点，否则像 reshardCollection 这类新命令根本不可见。
