1. wal 原理

1.1 redo log

1.2 sqlite wal

1. pgx.y，x 表示当前 page 的 num，y 表示当前 page 的版本，每个提交的事务都保存当前修改后的 page 副本；
2. 图中 wal 中提交了两个事务，wal 中蓝色框表示一个完整事务修改的所有 page；
3. wal 实际中保存的单位是 wal frame，除了修改的页面还会保存 page number checksum 等信息，这里为了突出展示了 page， 详细格式见：https://www.sqlite.org/fileformat2.html

1. 写操作总是发生在 wal 文件上；
2. 写操作总是追加在 wal 文件末尾，由 commit 触发；
3. 写入 wal 文件中是原始 page 修改后的副本；
4. 写操作对 wal 文件的访问是独占串行的；
5. 事务写入只有成功落盘（写入磁盘)才算成功提交，checkpoint 前会调用 wal 文件的 fsync，保证日志提交持久性和一致性；
6. 没有调用 fsync 不代表日志提交一定失败，会由文件系统定期回写；
7. 如果 fsync 回写之前发生 crash 或系统崩溃，导致事务 2 的 pg4.2 写 wal 失败，可校验出事务 2 不完整，则 wal 中成功提交的事务只有事务 1; 如果 pg0.1 回写失败，则 wal 中没有成功提交的事务。

关于读

1. 读与写可以并发；
2. 每个读事务会记录 wal 文件中一个 record 点，作为它的 read mark，每个事务执行过程中 read mark 不会发生改变，新提交的事务产生的修改不会影响旧的事务。read mark 会选择事务完整提交后的位置。原始 db 文件和 wal 中 read mark 之前的记录构成了数据库的一个固定的版本记录；
3. 读事务读一个 page 优先读 wal 文件，没有则读原始文件；
4. 如果一个 page 在 wal 中有多个副本，读 read mark 前的最后一个；
5. 同一个 read mark 可以被多个读事务使用。

1. checkpoint 针对 wal 中已经成功落盘的事务，每次 checkpoint 前会执行 fsync；
2. 每次 checkpoint 从前到后按序回写 wal 文件中尚未提交的事务到 db；
3. 如果 checkpoint 中途 crash，由于事务已持久化到 wal 文件，下次启动重新按序回写 wal 中的事务即可；
4. wal 中所有的事务 checkpoint 后，wal 文件会从头开始使用；
5. checkpoint 并不一定都会提交 wal 中全部的事务，如果只是部分提交，下次写入还是会写入 wal 文件的末尾，wal 文件可能会变很大；
6. 只有 truncate 的 checkpoint 才能清理已经异常变大的 wal 文件，会 truncate 文件大小到 0。

2.1 wal 和 wal-index 文件格式

2.2 文件多副本抽象

2.3 并发控制

3. wal 下的并发

3.1 锁的分类和作用

3.2 锁的持有情况

3.3 锁的应用

3.3.1 读写

1. wal文件存在 4 个已经提交的事务

   第一个事务修改了 page0，第二个事务修改了 page0、1、3，依此类推。
2. 当前数据库上存在 4 个活跃的连接，包括 3 个读事务和 1 个写事务；
3. 写事务独占了 WAL_WRITE_LOCK，所以此时不能再发起一个写事务；
4. 写事务占有 1（4）读锁，所以写事务读取不到 read mark 4 之后的修改，只能读取 read mark 4 之前的修改。即写事务读取 page4 时不能读取到 page4.3，只能读取 page4.0；
5. 3 个读事务占有 0（0），1（4），2（5）三个读锁，read mark 只能在事务结束的位置，不会处于中间 page 的位置；
6. 后续如果发起一个读事务，会占有读锁 3（7）。理论上可以发起任意多个读请求，读锁可以被 sqlite 连接共享。

3.3.2 checkpoint

1. 由于事务 0 持有 read lock 0，read mark 0，计算 mxSafeFrame 为 0，不会发生 checkpoint。

   如果事务 0 结束后发起 checkpoint。
2. 由于写事务存在，不能发起非 passive 的 checkpoint。

   如果事务 1 结束后执行 checkpoint。
3. 计算 mxSafeFrame 等于 4，会提交前 4 个 page，没有完全提交，wal 文件不会重新利用，新的写入还是会写入 commit transaction3 之后。

   如果所有事务结束后执行 checkpoint。
4. 提交所有页面，下次写入 wal 文件头部。

4. checkpoint 源码分析

4.1 调用链路

4.2 sqlite3_wal_checkpoint_v2

4.3 sqlite3Checkpoint

4.4 sqlite3BtreeCheckpoint

4.5 sqlite3PagerCheckpoint

4.6 sqlite3WalCheckpoint

4.7 walCheckpoint

5. 常见问题

5.1 checkpoint 何时触发

1. 手动调用 checkpoint 触发；
2. 通过 sql 语句 PRAGMA wal_checkpoint 触发；
3. sqlite 官方默认的 checkpoint 阈值是 1000 page，即当 wal 文件达到 1000 page 大小时，写操作的线程在完成写操作后同步进行 checkpoint 操作；
4. 当最后一个连接 close 时触发。

5.2 checkpoint 四种 mode 的区别

1. passive 不会加写锁，也就是不会 block 写操作；
2. 其他三种 mode 在回写 db 结束之前的逻辑都是一样。区别是 restart 会尝试再次独占获取读锁，保证 restart 型的 checkpoint 正常结束后，下一个发起的事务会从头开始循环利用 wal 文件。truncate 模式更近一步会 truncate wal 文件。

5.3 wal 下读写和 checkpoint 的并发性

1. 读和读可以同时进行；
2. 读和写可以同时进行；
3. checkpoint 和读事务也存在很大程度的并发，checkpoint 对读锁持有都是间歇性的，理论上都是耗时很短。仔细观察上面的源码分析部分，虽然会周期性持有读锁，基本上是等待读事务释放读锁，在真正耗时的 io 操作回写 wal 日志到 db 的过程中，还是可以发起读事务的。这种实现 checkpoint 对读存在着某种避让，读操作过于激进，会导致 checkpoint 饥饿，极端点会导致 wal 文件异常大；
4. passive checkpoint 和写事务，理论上也是可以并发；
5. 非passive checkpoint 和写事务，理论上不可以并发。

5.4 wal 文件巨大的原因 & 如何解决

5.4.1 原因

1. 非 passive 模式 checkpoint，需要获取 write lock，但获取不到；
2. passive 模式 checkpoint 过程中，有并发的写操作，导致 wal 中有未提交的日志；
3. checkpoint 没能及时获取所以读锁。

1. 事务耗时很长，导致锁迟迟不能释放；
2. 数据连接中存在锁丢失的情况，导致 checkpoint 永远不能获取到需求的锁；
3. 数据库连接过多，导致 checkpoint 过程中竞争不到锁。

5.4.2 解决方案

1. 尽量把无关代码移除事务，保证事务只做数据库相关的操作；
2. 检查代码，避免出现锁丢失的情况；
3. 读写操作适当退避，保证 checkpoint 有机会完全提交，而不总是部分提交。