磁盘空间不足时不能靠加GridFS或新建bucket解决，因其不提供扩容能力，真正占磁盘的是分片副本集的主节点数据目录；需定位高负载分片、执行compact回收碎片、或水平扩展添加新分片并显式分片fs.files和fs.chunks集合。
磁盘空间不足时，不能靠“加 GridFS”或“新建 bucket”解决——GridFS 本身不提供存储扩容能力，它只是把文件切块存进 fs.chunks 和 fs.files 集合，而这两个集合仍受底层分片集群的磁盘限制。
分片集群里哪个节点实际在吃磁盘？
真正占用磁盘的是每个分片（shard）所在副本集的主节点数据目录，不是 mongos 或 config server。查清瓶颈在哪台分片上，比盲目加机器更关键：
- 登录每台分片的 mongod 实例，运行
db.serverStatus().storageEngine确认dbPath路径 - 在对应服务器上执行
df -h /var/lib/mongodb（路径以实际dbPath为准） - 对比各分片的磁盘使用率，重点关注
Used%>85% 的节点；若只有 1–2 个分片高负载，说明数据分布不均，而非总容量不够
先检查是否能释放现有空间
很多“空间不足”其实是碎片或逻辑删除堆积导致的假性满载，WiredTiger 不会自动把空间还给操作系统：
-
db.runCommand({ compact: "fs.chunks" })和db.runCommand({ compact: "fs.files" })可回收内部碎片，但需停写或低峰期执行（compact 期间集合只读） - 删掉旧文件后，
fs.chunks文档虽被移除，但磁盘空间不会立刻下降；必须配合 compact 或mongodump+mongorestore重建才能真正 shrink - TTL 索引对
fs.files无效（uploadDate 不是过期字段），如需自动清理，得在业务层维护expireAt字段并建 TTL 索引
扩容必须走分片集群层面，不是单节点操作
想真正扩容，只能增加分片数量或扩展现有分片的磁盘——但后者受限于物理上限，长期看必须水平扩展：
- 添加新分片前，确保配置服务器（config server）有足够资源，且
mongos能连通新节点 - 执行
sh.addShard("rs-new-shard/xxx:27017")后，数据不会自动迁移；需对目标集合显式启用分片：sh.shardCollection("mydb.fs.chunks", {"_id": "hashed"}) -
fs.files必须单独分片：sh.shardCollection("mydb.fs.files", {"filename": 1, "uploadDate": 1})，否则它会卡在 primary 分片上成为瓶颈 - 分片后，balancer 默认开启，但大集合迁移可能持续数小时；观察
sh.status()中 chunks 分布和 migration 状态，避免某分片瞬间写入压力过大
容易被忽略的存储开销点
实际部署中，64MB chunk size、索引膨胀、oplog 和 journal 日志常被低估：
- 一个 1GB 文件在 GridFS 中生成约 16K 条
fs.chunks文档，加上 _id 索引、chunk 索引，真实磁盘占用可能达 1.3–1.5GB - reshardCollection 操作要求每个目标分片预留
(collection size + index size) * 2 / number of shards空间，不是简单除以分片数 - WiredTiger cache 占用内存，但磁盘缓存（filesystem cache）也依赖空闲空间；若
df剩余
