如何将 MongoDB 物理备份磁盘膨胀率降低 90% 的内核优化做到极致？

凌晨三点，告警群里炸了。某款头部游戏的MongoDB物理备份又一次把COS存储账单拉爆，磁盘膨胀率飙到惊人的200%。运维同学在群里发了个崩溃的表情，我盯着监控曲线，手心全是汗。那种看着存储投入成本像坐火箭一样往上冲，却无能为力的感觉，各个做过TB级MongoDB的人都懂，摆烂。。

我们当时用的还是常规思路：WiredTiger迅速照+oplog回放。从理论上讲很完美，在实际应用中却是个坑。WiredTiger的checkpoint机制会把全部被标记为hidden的节点数据也一起打包进去， 加上oplog本身的冗余复制，备份文件比线上数据较大一倍简直是常态。更糟的是这种膨胀不是线性增较长，是指数级的噩梦。

先说痛点：hidden节点和checkpoint是双沉重绞肉机

WiredTiger为了保证一致性，在做物理备份时会冻结一个逻辑时间段点。当前这个时间段点上，全部集合的数据页都会被遍历，即使这一些页在业务上已经是寒冷数据、甚至即将被drop掉。hidden节点的存在本意是隔离客户端写入， KTV你。 可备份线程根本不管这一些，它照单全收。我亲眼见过一个游戏服迁移后遗留的空集合，这是因为一直没清理整洁，引起每次备份更多带出几十GB垃圾。

我血槽空了。 oplog又是另一个吞噬者。很更多人以为oplog只是增量日志， 但物理备份场景下为了保证恢复完整性，系统会把整个oplog区间也打包进去。对于写放较大严沉重的业务，这一部分体积能占到总备份量的30%以上。你辛辛苦苦做压缩，最终还是结果是压缩完还是较大，这是因为日志本身就是不可压缩的乱序较小块。

腾讯云MongoDB团队的那次彻夜攻坚

后来我们跟着腾讯云MongoDB内核团队的思路做了拆解。他们没有去改应用层，而是从内核往外打了一套组合拳。先来看是精细化释放checkpoint。