调整MongoDB固定集合上限后存储大小未合理缩减的问题

问题背景 #

• 环境：单实例MongoDB 4.4.6，作为归档库使用，无专业运维人员
• 操作：将某固定（Capped）集合上限从156GB调整为50GB（执行convertToCapped命令）
• 异常情况：调整后集合实际数据量已符合50GB上限，但压缩后存储大小仍约76.8GB（预期低于30GB）；执行compact仅释放少量空间，因警告较多不敢使用repairDatabase()

补充统计数据（collStats） #

"size" : 53686822951.0,
"avgObjSize" : 646494,
"storageSize" : 82426355712.0,
"freeStorageSize" : 3994337280.0,
"maxSize" : NumberLong(53687091200),
"total size of bloom filters" : 0,
"checkpoint size" : 78431825920.0,
"file allocation unit size" : 4096,
"file size in bytes" : 82426355712.0,
"totalIndexSize" : 2600960,
"totalSize" : 82428956672.0,
"indexSizes" : {
    "_id_" : 2600960
}

注：集合WT文件大小：82426355712字节，索引文件大小：2600960字节

问题分析 #

从统计数据能看出：

• 实际数据量size已符合50GB上限要求，但storageSize仍保留原大文件占用
• WiredTiger存储引擎删除数据后，会把释放的空间标记为空闲（对应freeStorageSize），但不会主动收缩磁盘文件；compact默认仅整理空间、复用空闲块，不会强制收缩文件到实际所需大小

可行解决方案 #

方案1：重建Capped集合并迁移数据（推荐，风险低） #

适合无法停机、业务低峰期可操作的场景：

1. 创建新的50GB上限Capped集合：

db.createCollection("new_archive_coll", {capped: true, size: 53687091200})

2. 迁移原集合数据到新集合（Capped集合会自动保留最新数据，超出上限的旧数据会被自动淘汰）：

// 批量迁移避免单次操作超时
db.old_archive_coll.find().batchSize(100).forEach(doc => {
    db.new_archive_coll.insertOne(doc)
})

3. 验证数据一致性（对比文档数量、最新数据内容）：

db.old_archive_coll.countDocuments()
db.new_archive_coll.countDocuments()

4. 重命名集合替换原集合：

db.old_archive_coll.renameCollection("old_archive_coll_backup")
db.new_archive_coll.renameCollection("old_archive_coll")

5. 确认业务正常后删除备份集合：

db.old_archive_coll_backup.drop()

执行后磁盘文件会自动收缩到实际存储需要的大小

方案2：强制执行集合级compact命令 #

适合无法重建集合、可接受短时间阻塞的场景：

1. 在业务低峰期执行强制compact：

db.runCommand({compact: "your_collection_name", force: true})

注意：单实例执行compact会阻塞该集合的读写操作，需提前评估业务影响；该命令会尝试收缩磁盘文件，但效果可能因数据分布而异

方案3：离线repair数据库（适合可停机的场景） #

尽管有警告，但在已备份的前提下，归档库（数据修改少）的repair风险可控：

1. 停止MongoDB服务
2. 完整备份数据库目录（重要！防止数据异常）
3. 执行repair命令：

mongod --repair --dbpath /path/to/your/mongodb/data

4. 启动MongoDB服务，检查存储大小和数据完整性

内容的提问来源于stack exchange，提问作者Asaf