fix(wal): checkpoint 重写改为临时文件+原子 rename,堵住崩溃丢数据窗口#159
Conversation
doRewrite 此前就地 Truncate(0)→重写→Sync,三步非原子。若在 Truncate 之后、 重写 fsync 之前崩溃,WAL 被清空/残缺——而 checkpoint 快照的 active+dirty 此刻 尚无 SSTable 副本,会静默丢失已 ack 的写,违背"Append 返回即已落盘"契约。 改为标准原子替换:records 写满并 fsync 到 wal.log.tmp,os.Rename 覆盖(POSIX 原子), 再 fsync 父目录让 rename 持久。恢复时只会看到完整旧 WAL 或完整新 WAL,绝不残缺。 仍只由 flushLoop 执行,维持文件唯一写者不变式。抽出 encodeRecord 供 append/rewrite 复用。 新增 TestWALRewriteAtomicReplace:预置陈旧 .tmp 残留不干扰恢复;重写后恰只剩新记录 (含墓碑/空值边界)、可继续 Append、重开仍完整。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 20 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🐯 BanGD 数据库内核评审模型原始输出片段(调试用) |
问题
doRewrite(#157 引入)就地Truncate(0)→ 重写 →Sync,三步非原子。若在Truncate之后、重写fsync之前进程崩溃,WAL 被清空/残缺——而 checkpoint 快照的active+dirty此刻尚无 SSTable 副本(正因如此才在快照里),会静默丢失已 ack 的写,违背"Append返回即已 fsync 落盘"的契约。修复
标准原子替换:
records写满并fsync到wal.log.tmp→os.Rename覆盖(POSIX 原子)→fsync父目录让 rename 持久。恢复时只会看到完整旧 WAL 或完整新 WAL,绝不残缺。仍只由flushLoop执行,维持文件唯一写者不变式。验证
TestWALRewriteAtomicReplace:陈旧.tmp残留不干扰恢复;重写后恰只剩新记录(含墓碑/空值边界)、可继续Append、重开仍完整。全量-race通过。🤖 Generated with Claude Code