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() 优化慢查询，减少无效扫描与写入放大，从源头控制空间增长。

安全操作清单

• 任何结构性变更前先做全量备份（如 mongodump），变更中保持监控与回滚预案，变更后在低峰期窗口执行并逐步观察。
• 执行 compact、主从切换、迁移数据目录等高风险操作务必在维护窗口完成，并提前通知业务方。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！