Debian系统MongoDB存储空间管理 - 问答

容量评估与监控

在实例层面，磁盘使用由两部分构成：data_size（集合数据与索引）与 log_size（如 local 库、运行日志、审计日志等）。当使用率达到约**80%**时，应优先通过“释放空间或扩容”来规避写满风险。
在数据库/集合层面，使用 db.stats() 与 db.collection.stats() 定位占用与碎片；WiredTiger 删除文档后通常不会立即把空间返还给操作系统，而是留作“可重用空间”，碎片会逐步累积。
在系统层面，使用 df -h 与 du -sh /var/lib/mongodb 观察挂载点与数据目录用量；结合 mongostat、mongotop 观察写入速率、脏页与热点集合，提前识别增长趋势。

扩容与迁移

原地扩容磁盘后扩展分区与文件系统
1. 扩展分区：例如使用 growpart /dev/sda 1；
2. 扩展文件系统（如 ext4）：resize2fs /dev/sda1；
3. 验证：df -h；
4. 必要时重启 mongod：sudo systemctl restart mongod。
迁移数据目录到更大磁盘
1. 停止服务：sudo systemctl stop mongod；
2. 迁移数据：rsync -av /var/lib/mongodb/ /data/db/；
3. 修正权限：sudo chown -R mongodb:mongodb /data/db；
4. 修改 /etc/mongod.conf：storage.dbPath: /data/db；
5. 启动：sudo systemctl start mongod；
6. 验证状态与路径是否正确。
架构级扩容
- 副本集：增加节点可提升容量与可用性，但单节点磁盘并不会自动扩容；
- 分片集群：通过增加 shard 将数据水平切分，从根本上扩展可存储容量。
重要提示
- MongoDB 本身不提供“自动扩容”，需结合监控告警与脚本/平台能力实现“自动加盘或自动加节点”的流程化扩容。

空间回收与碎片治理

何时考虑回收
- 当磁盘使用率长期高于80%~85%且碎片率较高（如超过25%）时，回收收益明显。
集合级碎片回收（WiredTiger）
- 副本集建议先对从库执行 compact，随后进行主从切换，以降低对业务影响；
- 命令：db.runCommand({compact:“collectionName”})；
- 影响：会阻塞集合/索引的创建与删除，存在一定负载与时延，务必在低峰期执行。
特殊集合
- oplog.rs：在延迟恢复或物理备份后可能占用异常，可对其单独 compact（需具备相应权限）：
  - 授予权限：db.grantRolesToUser(“root”, [{db: “local”, role: “dbAdmin”}])
  - 执行：use local; db.runCommand({ compact: “oplog.rs”, force: true })
重要认知
- compact 主要“整理碎片并释放可重用空间”，并不等同于把空间“归还给操作系统”；若需真正释放到 OS，仍需配合“扩容磁盘/迁移数据目录”等手段。

配置与日常运维要点

存储与日志配置
- 确认使用 WiredTiger 引擎；合理设置 storage.wiredTiger.engineConfig.cacheSizeGB（依据内存与业务权衡）；
- 启用 systemLog.logAppend: true，避免日志轮转时反复覆盖；
- 按需调整 dbPath 与 logPath，并确保目录属主为 mongodb:mongodb。
容量阈值与告警
- 建议设置磁盘使用率阈值（如80%）并结合 Prometheus/Grafana 或脚本告警，触发“清理/扩容/加节点”的预案流程。
查询与索引治理
- 建立必要索引、避免冗余索引，使用 explain() 优化慢查询，减少无效扫描与写入放大，从源头控制空间增长。

安全操作清单

0 赞

0 踩