Ubuntu下MongoDB如何管理磁盘空间

Ubuntu下MongoDB磁盘空间管理

一 容量监控与日常巡检

• 查看数据库与集合容量概览：
  • 列出所有数据库及大小：db.adminCommand({ listDatabases: 1 })
  • 查看当前库存储统计：db.runCommand({ dbStats: 1 })
  • 查看集合统计（含大小、索引等）：db.runCommand({ collStats: “yourColl” })
• 观察文件系统剩余空间：在 Ubuntu 上用 df -h 查看数据盘与日志盘使用率，提前预警。
• 容量规划要点：MongoDB 删除数据或集合后，空间通常不会立即归还给操作系统，需结合回收手段（如 compact、重建、重同步、备份恢复）才能真正释放空间。

二 释放与回收空间的可选方案

• 使用 compact 回收集合空间（WiredTiger）

  • 作用：重写数据/索引文件，尝试把被删除文档占用的页归还给操作系统；对大集合较耗时。
  • 版本差异：
    • 4.4 之前：compact 会阻塞该库的大多数读写操作。
    • 4.4 起：仅阻塞部分 DDL（如 dropCollection、createIndex、dropIndex、collMod），其他操作通常可用。
  • 副本集注意：主节点不会把 compact 复制到从节点，如需回收各节点空间，需在对应节点分别执行。
  • 示例：use yourDB; db.runCommand({ compact: “yourColl” })。

• 重建索引以缩小索引体积

  • 删除大量文档后，索引可能“虚胖”。可删除后重建，或一次性重建：
    • 方案A（可控）：db.yourColl.dropIndex(“idx_name”); db.yourColl.createIndex({…});
    • 方案B（全量）：db.yourColl.reIndex();
  • 注意：reIndex 会删除并重建除 _id 外的所有索引，耗时长，建议在低峰期执行。

• 副本集节点重同步（不中断主业务的最佳实践）

  • 思路：让某个 secondary 节点先下线并清空数据目录，再加入集群自动全量重同步；重同步后得到“紧凑”的数据文件，从而释放空间。
  • 简要步骤：
    • 主库（如必要）降级：rs.stepDown(120)
    • 主库移除该 secondary：rs.remove(“ip:port”)
    • 在 secondary 上清空其 dbPath 数据文件
    • 重新加入集群：rs.add(“ip:port”)，等待数据追平
    • 对多个节点重复上述过程
  • 优点：基本不阻塞业务读写；缺点：需要额外磁盘空间与一定的同步时间。

• 备份-恢复（mongodump/mongorestore）或 repairDatabase

  • 备份恢复法（通用且干净）：
    • mongodump -d yourDB -o /backup/yourDB
    • 连接 mongo 执行：use yourDB; db.dropDatabase()
    • mongorestore -d yourDB /backup/yourDB
  • repairDatabase（谨慎）：
    • 在 mongo shell：db.repairDatabase() 或 db.runCommand({ repairDatabase: 1 })
    • 会重建数据文件并丢弃无效/损坏数据，通常能回收空间，但可能耗时较长并影响可用性；执行前务必做好完整备份。

三 空间不足时的应急与配置

• 快速止血
  • 优先清理可删除的数据/集合，或临时扩容磁盘分区。
  • 若因 journal 空间不足导致无法启动（如日志提示 Insufficient free space for journal files），可在启动参数中临时加入 –smallfiles（或配置文件中设置 smallfiles=true），以使用较小的默认 journal 文件大小，尽快恢复服务，再规划长期方案。
• 避免不当操作
  • 不要使用 kill -9 结束 mongod，可能导致锁文件残留或异常；异常关闭后如出现启动失败，可检查并清理 mongod.lock，必要时以 –repair 方式修复后再启动。

四 长期治理与容量优化

• 用 TTL 索引自动过期历史数据
  • 示例：db.RawMessage.createIndex({ “generatedTime”: -1 }, { expireAfterSeconds: 31536000 })（按你的时间字段与保留周期调整）。
  • 说明：TTL 由后台线程定期清理（默认每 60 秒 检查一次），清理后空间不一定立即归还给操作系统，可与 compact/重建/重同步配合回收。
• 定期重建索引与清理无用索引
  • 数据大幅裁剪后，重建热点索引以回收索引空间；删除不再使用的索引，减少写入放大与空间占用。
• 压缩与存储策略
  • 在支持的版本与引擎上，评估并选择合适的压缩算法（如 zstd 相对 snappy 可获得更高压缩率），以降低存储占用、延缓扩容周期。