题干与适用场景
一个桌面同步服务在多个进程中打开同一个 SQLite 文件，数据库使用 WAL 模式。团队发现历史版本可能存在 WAL-reset bug，担心升级过程中误判数据安全、触发并发写入或把损坏副本继续同步。请设计从版本盘点、风险判定、升级、完整性验证、备份恢复到回滚的方案，并说明如何治理多进程访问。
面试官考察点
- 能否区分“受影响版本”与“实际触发条件”，避免把理论风险夸大成已损坏事实。
- 能否根据官方修复版本和回移版本制定升级矩阵。
- 能否设计一致的备份、校验、隔离和恢复顺序。
- 能否解释
PRAGMA integrity_check的边界，而不是把它当成所有业务正确性的证明。 - 能否处理多进程写入、checkpoint、文件复制和同步下游的副作用。
回答前需要澄清的问题
- 当前 SQLite 精确版本、编译选项、操作系统和数据库是否持续使用 WAL？
- 是否存在两个以上进程或线程同时对同一文件写入或 checkpoint？
- 数据库是否有可验证的备份、同步副本和最后一次成功校验时间？
- 升级是否允许短暂停写，客户端是否能强制退出旧进程？
- 数据损坏的容忍度是什么：可丢失最近事务、可从服务端重建，还是必须原样恢复？
30 秒回答
我会先做版本与运行模式盘点，不把“版本落在受影响范围”直接等同于已经损坏。SQLite 官方说明 WAL-reset bug 影响 3.7.0 到 3.51.2 的部分 WAL 场景，3.51.3 及之后修复，另有少数回移版本。升级前冻结写入，复制原文件和 WAL/SHM 相关材料，记录校验基线；在隔离副本上升级并运行完整性检查、业务抽样和同步一致性校验。通过后再切换生产文件，保留可回滚副本。长期治理上限制同文件多进程写入，监控 checkpoint、锁冲突和校验失败，并把恢复演练纳入发布门禁。
分步骤深入解答
1. 建立影响矩阵
官方资料指出，WAL-reset bug 可能存在于 3.7.0 至 3.51.2，修复版为 3.51.3 及以后，部分旧分支有 3.44.6 和 3.50.7 回移修复。风险还需要同时满足 WAL 模式、同一文件的多个连接，以及写入或 checkpoint 在紧密时间窗口交错。先记录每个客户端的 SQLite 版本、WAL 状态、连接数、进程模型和文件位置，再按“受影响版本 + 触发条件是否存在”分层。
版本与模式 -> 是否使用 WAL -> 是否多连接/多进程 -> 是否存在并发写入与 checkpoint
| | | |
+-- 升级门禁 ----+-------------------+----------> 隔离验证与恢复演练2. 冻结与取证
发布窗口先停止新写入，让应用优雅关闭连接；无法确认旧进程已退出时，不复制或替换数据库。保存原数据库、同目录的 WAL/SHM 文件、版本信息、最近备份和校验日志。任何复制都应在稳定状态下进行，避免把正在变化的 WAL 当成静态快照。
3. 隔离升级与校验
在副本上使用修复版本打开数据库，先做 SQLite 层完整性检查，再做应用层抽样：行数、关键索引、外键关系、同步游标和最近事务。integrity_check 能发现部分结构问题，但不能证明业务语义、远端副本或未提交事务都正确。校验结果必须关联数据库副本哈希和工具版本。
4. 切换、回滚与恢复
通过门禁后原子切换文件路径或版本目录，旧副本只读保留。若启动后出现校验失败、同步冲突或业务数据缺口，立即停止新写入，切回旧副本或从可信备份重建，再进行增量同步。不要在疑似损坏文件上继续执行 VACUUM、批量修复或覆盖式复制，以免丢失取证材料。
5. 多进程与 checkpoint 治理
优先把同一文件的写入集中到单一进程，通过请求队列串行化写事务；其他进程使用受控读连接。明确 checkpoint 的触发方、超时和失败告警，避免多个组件同时主动 checkpoint。若必须多进程协作，记录连接生命周期、锁等待、checkpoint 结果和进程版本，并用压力测试重现写入与 checkpoint 交错。
6. 监控与恢复演练
发布后监控 SQLite 版本覆盖率、WAL 文件增长、checkpoint 延迟、锁冲突、完整性检查失败、同步重试和恢复耗时。定期用脱敏副本演练“冻结—备份—校验—切换—回滚”，验证旧客户端不会重新写入旧版本数据库。恢复目标应以业务 RPO/RTO 表示，不能只写“有备份”。
高质量示范回答
我会先建立影响矩阵：SQLite 版本是否在 3.7.0–3.51.2、是否使用 WAL、同一文件是否有多个连接，以及是否可能同时写入和 checkpoint。版本落入范围只说明需要升级和验证，不说明文件已经损坏。生产窗口冻结写入并确认旧进程退出，保存数据库、WAL/SHM、备份、版本和哈希；在隔离副本上升级到 3.51.3 或可接受的回移修复版。
验证分三层：PRAGMA integrity_check 检查结构，应用抽样检查关键数据和索引，同步校验检查本地与远端游标。通过门禁后原子切换，保留旧副本只读。如果出现校验或业务缺口，停止写入、回滚到可信副本并重建增量同步。长期上把写入集中到单一进程，限制主动 checkpoint，监控锁冲突与校验失败，并定期演练恢复。
常见错误
- 只看到旧版本就断言“数据库已经损坏”。
- 只升级二进制，没有冻结写入、保留 WAL/SHM 和可回滚副本。
- 把一次
integrity_check通过当成业务数据完全正确。 - 在疑似损坏文件上直接 VACUUM 或覆盖复制，破坏取证证据。
- 允许多个进程各自 checkpoint，却没有冲突和超时监控。
- 只说“定期备份”，没有定义备份一致性、RPO、RTO 和恢复演练。
追问及应对
如果版本受影响但没有发现异常，是否可以跳过升级？
不应跳过。应结合触发条件评估短期风险，同时安排修复版本升级；“未观察到异常”不能证明极窄时间窗口的竞态不存在。
PRAGMA integrity_check 通过后，为什么还要做业务校验？
它主要检查数据库结构和部分约束，不能验证同步游标、领域不变量、远端一致性或最近事务是否完整，所以需要应用层抽样和副本比对。
多进程无法立即改造，临时措施是什么？
先统一 SQLite 版本和启动参数，禁止不受控的主动 checkpoint，串行化写事务并提高锁冲突观测；同时缩短灰度批次，保留可快速切换的只读备份，直到单写入者方案落地。