第 12 篇 说明块无覆盖写入:删数据往往不会自动缩小文件——空闲块若不在文件尾,无法 truncate。Architecture Guide Compaction:compaction 是 B-Tree 层与 Block Manager 协作,尽量把尾部块搬到文件前部可复用区间,再截断文件;best-effort,不保证缩小。
Backup 与 logging 的交互在 Logging 已出现:backup cursor 存活期间禁用自动删日志与预分配改名。本文把 compaction 流程与 backup 契约收在一处。
本文是「WiredTiger 内核」系列第 13 篇(共 17 篇)。→ 系列目录
先修:第 9–10、12 篇。续读:第 14–15 篇。
版本锚定:Architecture Guide Version 12.0.0 /
developCompaction、Logging、Block Manager;源码mongodb-8.0的src/block/block_compact.c、src/btree/bt_compact.c。
一、为何需要 compaction
Checkpoint 引用若干磁盘块;脏页 reconcile 后新 checkpoint 引用新块,旧 checkpoint 删除后旧块进 avail。Avail 若分散在文件中部,文件系统报告的文件大小不变。Compaction:把文件尾部的块拷到前部可复用块,使尾部可 truncate。
二、流程要点
- 先做一次全库 checkpoint:尽量刷脏、丢掉旧 checkpoint,让 avail 列表尽可能大。
- 跳过过小文件(Guide:小于 1MB)或理论可回收空间低于
free_space_target的文件。 - 硬编码门槛之一须满足(Guide):
- 至少 20% 可用空间落在文件前 80%(则尝试重写最后 20%);或
- 至少 10% 总文件大小在前 90% 可用(则尝试最后 10%)。
- Compaction 期间 block manager 用 first-fit 最大化前移。按逻辑顺序走树,用 BM API 判断搬迁某 leaf 是否有益;可在不把 leaf 拉进 cache 的情况下重写块,并弄脏父 internal,以便后续 checkpoint/eviction 重写地址链。
- 每轮之后执行 两次 checkpoint:第一次释放的块先进「checkpoint-available」特殊列表,元数据更新后才进真正 avail;第二次/后续才能避免「checkpoint 自己又写在文件尾导致无法截断」的问题(Guide 详述两步语义)。具名 checkpoint 若未显式删除/替换,可能让 compaction 无效。
可开 verbose=[compact,compact_progress]
与相关 statistics 观察进度。
Background compaction
后台服务遍历元数据中的合格文件(排除 tiered、exclude
列表),跳过前述「开头那次」checkpoint
以降低打扰;用历史成功率聚焦有效表;仅当 dirty(不计
updates)低于 eviction_dirty_trigger 且总 cache
低于 eviction_trigger 时处理下一张表。经同一
WT_SESSION::compact API 启停配置。
三、Backup 契约(与 Logging)
Logging:
- Backup cursor 打开期间:禁用自动日志删除;禁用预分配日志文件改名——保证 cursor 打开时存在的文件(或可能返回的名字)在生命周期内仍在;用户也可能直接拷目录。
- Log cursor 打开时同样禁用自动删除。
工程含义:长时间挂着 backup cursor 会让
WiredTigerLog.* 堆积;备份窗口应有界。MongoDB
备份工具如何映射到 WT backup cursor,属产品层(第 14
篇只标边界,不写 Ops Manager 手册)。
Checkpoint 也可由 backup 路径内部触发(第 9 篇 Internal callers)。
四、收束
- Compaction = 尾块前移 + 多次 checkpoint 后 truncate;不保证缩小。
- Backup cursor 期间日志删除/预分配停摆——一致性优先于空间。
- 下一篇:MongoDB 嵌入边界——参数如何映射到本系列机制。
参考资料
- WiredTiger Architecture Guide, Compaction:https://source.wiredtiger.com/develop/arch-compact.html
- Logging、Block Manager、Checkpoint
- 系列索引
上一篇:Block
manager
下一篇:MongoDB
嵌入边界
同主题继续阅读
把当前热点继续串成多页阅读,而不是停在单篇消费。
【WiredTiger 内核】文档库存储引擎全景:MongoDB 默认引擎的生态位
定位文档库默认引擎 WiredTiger 相对 PG/InnoDB/SQLite/RocksDB 的生态位;钉住 Session→Cache→Reconcile→HS→Checkpoint 主线、站内分工与 17 篇阅读路线,并以 Berenson 隔离词汇与 Durable History 为学术/工程锚点。
【WiredTiger 内核】Reconciliation:内存页到 on-disk image
拆解 WiredTiger reconciliation:把 in-memory 页转为 on-disk image、按 leaf_page_max 与 split_pct 分裂,并在用户表 reconcile 时选出最新已提交值、将更旧更新写入 History Store;锚定 wiki 与 src/reconcile/。
【WiredTiger 内核】Checkpoint:跨文件一致快照
拆解 WiredTiger checkpoint 算法:先借 eviction 减压,再按用户表→History Store→元数据顺序 reconcile 并原子切换;说明 checkpoint generation 与 eviction 的可见性约束,以及与 journal 的耐久分工。
【WiredTiger 内核】Journal / Logging:Checkpoint 之间的 WAL
拆解 WiredTiger write-ahead log:WiredTigerLog 文件、LSN、slot 无锁写入、checkpoint 之后自动删日志,以及崩溃恢复时从最近 checkpoint 回放;并标出与 MongoDB journaling 配置的边界。