Tailscale 用六个月抓住 SQLite 16 年数据竞争：可靠技术也怕非标准用法
作者：林岚｜OC 开发者生态编辑
林岚
Tailscale 公开了过去半年反复宕机的根因：一个潜伏在 SQLite 中约 16 年的 WAL-Reset 数据竞争。公司经历了 19 次数据库损坏，最终与 SQLite 核心开发者合作定位并修复问题。
一句话结论：问题不在 SQLite 突然变得不可靠，而在 Tailscale 使用了合法但少见的激进手动 checkpoint；规模把一个极窄的竞争窗口放大成了会重复发生的生产事故。
Tailscale 的控制平面按 shard 拆分，每个 shard 由单个 Go 进程独占一份 SQLite 数据库。这原本符合 SQLite 的典型使用方式。不同之处在于，Tailscale 为了快速、稳定地生成完整备份，主动控制 WAL checkpoint，并且执行得非常频繁。
WAL 模式先把新页面写入预写日志，再通过 checkpoint 拷回主数据库。漏洞发生在 checkpoint 与写事务同时撞上一个极窄时间窗口时：checkpoint 错误地认为某些页面已经复制，实际却没有写入。其他引用这些页面的数据继续落盘，最终留下结构不一致的数据库。
这类问题最难查，因为它没有稳定触发条件。故障有时相隔几小时，有时安静六周。Tailscale 只能在生产环境加入被动取证遥测，并建立额外的 SQL 事务日志。两次事务回放失败提供了关键线索：一个已经提交的写入，竟然对后续事务不可见。
SQLite 开发者为此制作 tmstmpvfs 调试 shim，最终抓到竞争条件。修复最初进入 3.52.0，但该版本又因为表达式索引兼容问题被撤回；WAL-Reset 修复随后进入 3.51.3，3.53.0 也包含修复和自愈表达式索引能力。SQLite 官方说明，受影响条件需要 WAL 模式、同一文件至少两个连接，并发写入与 checkpoint 同时发生，普通用法很难自然触发。
关键事实
- 来源：Tailscale 工程博客、SQLite 官方文档
- 影响：六个月内 19 次数据库损坏；早期恢复停机超过一小时
- 根因：WAL checkpoint 与写事务之间的罕见数据竞争
- 修复版本：SQLite 3.51.3 及之后版本；3.52.0 已撤回
OC 判断
“无聊技术”仍然是好选择，但只有常见路径真正享受了多年集体测试。团队一旦接管数据库原本自动完成的 checkpoint、同步或恢复流程，就已经在维护一套自己的数据库运行时。此时必须为异常路径增加遥测、回放和故障注入，而不能只依赖组件名气。
为什么重要
- 对开发者：使用 WAL 且自行管理 checkpoint 的应用应尽快确认 SQLite 版本和连接模型。
- 对运维团队：备份通过不代表数据库可靠，持续执行
PRAGMA integrity_check才能较早发现问题。 - 对开源生态：商业支持合同与生产遥测共同帮助修复了一个影响所有用户的长期缺陷。
评论
围绕这篇文章补充信息、提出问题或分享观察。