MongoDB 5.0重分片时空间不足怎么办？确保每个分片有足够预留空间进行临时存储
重分片失败报 NotEnoughDiskSpace 怎么办
遇到这个报错，直接原因很明确：MongoDB在迁移数据块时，目标分片需要额外的“周转”空间来存放副本数据。这包括正在迁移的临时数据块、oplog缓冲，以及WiredTiger缓存操作带来的磁盘占用。一旦磁盘使用率逼近90%，MongoDB 5.0的硬性限制就会启动——它默认拒绝在剩余空间少于10GB或5%的分片上启动任何迁移任务。注意，这不是一个可调节的配置项，而是内置的硬性规则。
那么，第一步该做什么？
- 别只看
df -h的表面数字：真正的磁盘压力可能藏在WiredTiger的日志和缓存里。务必通过db.serverStatus().metrics.repl.buffer和db.runCommand({ “serverStatus”: 1 }).wiredTiger.cache来查看实际的复制缓冲与缓存状态，这比单纯的磁盘剩余空间更能反映内存和I/O的真实压力。 - 快速腾挪空间的有效手段：清理旧的oplog日志通常是立竿见影的方法。执行
db.runCommand({ “logRotate”: 1 })（前提是已开启日志轮转功能），然后手动删除那些/var/log/mongodb/mongod.log.*之类的归档日志文件。 - 一个绝对要避免的“雷区”：千万不要图省事，直接用
rm -rf去删除data/db/目录下的*journal或*wt文件。这会直接破坏WiredTiger存储引擎的元数据完整性，导致整个分片实例无法启动，后果严重。
如何安全预留 20% 磁盘空间给重分片
为重分片预留空间，思路不应该是简单地“购买更大磁盘”，而是要让MongoDB自身具备感知并主动维持安全水平的能力。这里的关键，在于wiredTiger.engineConfig.configString和storage.wiredTiger.engineConfig.cacheSizeGB这两个参数的协同配置。
- 核心配置策略：在每个分片的
mongod.conf配置文件中，进行如下显式设置：storage:
其中，
wiredTiger:
engineConfig:
configString: “cache_size=8G,eviction_target=80,eviction_trigger=90”eviction_target=80意味着当缓存占用率达到80%时，WiredTiger就开始主动驱逐旧的数据页；而eviction_trigger=90则是一个硬性上限，超过此值写入操作就会被阻塞——这套机制从源头间接防止了磁盘被意外填满。 - 缓存大小的黄金法则：
cacheSizeGB的值必须控制在物理内存的60%以内。如果设置过大，操作系统的OOM Killer可能会直接终止mongod进程。例如，当缓存设为8GB时，根据数据块的平均大小估算，相应的磁盘预留空间至少应达到20GB。 - 热生效技巧：在重启分片实例之前，可以尝试先运行
db.adminCommand({ “setParameter”: 1, “wiredTigerEngineConfigString”: “eviction_target=80” })命令，让部分参数在MongoDB 5.0及以上版本中即时生效，减少服务中断时间。
重分片期间监控哪些指标才不会漏掉空间告警
仅仅依赖db.printShardingStatus()或云服务商Atlas界面上的“分片容量”视图是远远不够的。要确保万无一失，必须紧盯下面这三个实时指标：
- 分片数据总量：通过
db.runCommand({ “top”: 1 }).totals[“dataSize”].totalSize查询当前分片的总数据量。建议每5分钟检查一次，目的是确认数据增长曲线是否正常，有没有出现某个集合数据量突然暴增的异常情况。 - 数据块分布均衡性：使用
db.getSiblingDB(“config”).chunks.countDocuments({ “shard”: “shard01” })来对比各个分片上的数据块数量。如果发现某个分片的数据块数量在短时间内激增超过30%，那很可能意味着迁移任务正在向该分片密集写入，此时必须立刻检查该分片磁盘的I/O等待时间（使用iostat -x 1命令）。 - 系统级隐藏杀手：inodes：监控
/proc/mounts中对应挂载点的inode使用率（命令是df -i）。这是一个极易被忽略的细节。即使磁盘还有剩余空间，一旦inode使用率达到95%以上，WiredTiger引擎将因为无法创建新的文件而卡住整个迁移过程。
紧急情况下跳过空间检查的风险与操作
必须明确一点：在MongoDB 5.0中，并没有提供一个可以简单关闭NotEnoughDiskSpace检查的开关。所谓的“跳过”检查，实际上只有两种具备可操作性的路径，而且每一种都伴随着明确的风险和副作用。
- 路径一：临时“隔离”分片：手动修改配置服务器（config server）上
shards集合中对应分片的host字段，例如将端口改为一个临时未使用的端口（如shard01/localhost:27018）。这样，均衡器（balancer）会认为该分片“暂时离线”，从而停止向它迁移数据。等重分片主要任务完成后再改回原端口。但副作用是，这会导致集群中部分数据块分布在一段时间内处于失衡状态。 - 路径二：腾笼换鸟：使用
mongodump备份并mongorestore --drop恢复的方式，清空一些优先级较低的数据库以腾出空间。这里有一个关键陷阱：mongorestore默认不会保留原集合的分片键配置。因此，在恢复分片集合时，必须额外添加--shardedCollection参数来指定集合名，否则恢复后的数据将无法被正确路由，导致查询异常。
最后，分享一个真正容易被忽略的细节：在重分片过程中，所有Secondary节点上的local.oplog.rs（oplog集合）大小，会随着数据迁移的节奏产生剧烈波动。如果oplog只使用了默认的5%磁盘配额，它很可能在迁移高峰期吃掉本应预留给数据块迁移的宝贵空间。因此，一个稳妥的做法是：在所有分片节点上，执行db.getSiblingDB(“local”).runCommand({ “collMod”: “oplog.rs”, “oplogSizeMB”: 10240 })命令，手动将oplog容量扩大（例如到10GB）。请注意，修改此配置需要重启mongod实例才能生效。
