PostgreSQL 技术内幕 (十)WAL log 模块基本原理

事务日志是数据库的重要组成部分，记录了数据库系统中所有更改和操作的历史信息。 WAL log(Write Ahead Logging)也被称为 xlog，是事务日志的一种，也是关系数据库系统中用于保证数据一致性和事务完整性的一系列技术，在数据库恢复、高可用、流复制、逻辑复制等模块中扮演着极其重要的角色。

在这次直播中，我们为大家介绍了 WAL log 模块的基本原理、构成和特性。以下内容根据直播文字实录整理而成。

WAL log 简介

数据库在写入或更新资料时，要确保事务始终保持 ACID 的特性。当系统发生故障时，数据库通过事务日志回放来保证故障恢复后数据不丢失。

图 1：单机 WAL log 流程示意图

如图 1 所示，在单机场景下，如果每一次写入或更新都直接去写表文件，单次更新表文件的代价相对高昂，对于硬盘来说随机写的性能也会非常差。此时，可以通过引入缓冲池（Buffer Pool），将数据写入内存中。相比直接写表文件，这种方式的性能更高。

同时，为了保证数据的持久化，需要引入 WAL log：在内存更新前，先写入 WAL log，再更新内存。在这种情况下，即使出现了断电或故障等情况，也能准确地恢复数据，保证了数据库的 ACID。

相比直接去更新表文件，WAL log 代价更小，执行路径更短。在 PostgreSQL 中，WAL log 的写入也属于随机写。

图 2：联机 WAL log 流程示意图

除此之外，WAL log 在联机场景下还可以支持主从同步，以及热备份等功能。

以 Greenplum 为例，如果没有引入 WAL log ，主从之间需要约定好一份同步/备份的协议，或者是在从节点执行同样的 SQL 语句，这样不仅操作复杂，而且很难做到热切换。

在引入 WAL log 之后，主从节点之间直接同步 WAL log，就能够保证数据的一致性。当主节点发生故障时，从节点也能快速地通过相应的 WAL log 重放，让数据恢复到可使用的状态，整个过程操作更为简便。

WAL log 实现方式

不同的数据库对 WAL log 实现的需求点也有所区别，主要体现在四个方面：

• 首先是格式，一般由 meta+data 两个部分组成。meta 部分记录了关联资源的元信息，data 是资源自定的裸数据。meta 和 data 可以分开存储，也可以统一存储。分开存储时，单条 WAL log 需要先读取完整的 meta，再按需求解 data；统一存储时，可以一条条解。举个例子，在分开存储时，数据组成往往是 meta1+meta2.. metaN+data1+data2...dataN；而在统一存储时，数据组成往往是 meta1+data1+meta2+data2...metaN+dataN。

• 其次，在修改数据时有 undo log 和 redo log 两种方式。undo log 从后往前写，redo log 从前往后写。PostgreSQL 采用的是 redo log。

• 此外，循环校验码信息（CRC）分为完整数据和分段数据两种。分段 CRC 的优点是当出现错误时，能够快速定位到坏的块数据，且损坏的范围很小，但代价是速度较慢；相比之下，完整数据的 CRC 读写速度更快，但如果单个 meta 损坏，则可能导致整个 WAL log 都损坏，恢复成本较高。

• 最后，是否需要落盘，这主要取决于具体场景，如果只做同步和备份，可以考虑不落盘。

WAL log 的组成

在 PostgreSQL 中，WAL log 由头部、块头部、块私有数据块、自定义资源数据块四部分组成。

图 3：PostgreSQL 中 WAL log 构成图

头部和块头部，相当于上面提到的 meta，主要用于数据块的快速定位、数据块的描述以及对数据块 CRC 操作等。其中，块头部是私有的，需要和 page 绑定。而块私有数据和 WAL log 本身数据属于 data 部分，用于存储具体的数据。

在 WAL log 本身数据中，初始化资源管理器 rmgr(Resource managers definition)是自定义资源的主要载体，也是 WAL log 数据块内容的生产与消费者。

WAL log checkpoint

WAL log 在执行过程中，数据量会不断地累积，当达到一定数量后，会对系统性能产生影响，因此需要定时清理 WAL log 数据。

清理页缓存和 xlog 文件需要借助 checkpoint（检查点）机制。执行 checkpoint 之后，页缓存可以被清空，这样可以保证不会因为页缓存太大而导致性能下降。

checkpoint 的主要作用包括脏数据块回写、xlog 回收（非 archive xlog 且已同步的 xlog）和 checkpoint redo。

通常触发 checkpoint 的时机主要有包括按时定期清理、数据最大长度限制、checkpoint 语句、数据库关闭在内的四种场景。当然在其他场景下，也可能会触发 checkpoint，这里不再一一列举。

自动 checkpoint 指的是按照一定的时间间隔执行 checkpoint 命令，时间间隔在 PostgreSQL.conf 文件中可以配置，默认是 5 分钟。

WAL log recovery 与 replay

如图 4 所示，在 GPDB 中，数据恢复的过程包含了数据重放。数据库启动时，会有 startup 进程打开 checkpoint redo 文件，开始按顺序读取 xlog，进行恢复操作。

图 4：recovery 流程示意图

在联机场景下，primary/master 集群完成数据恢复后，会退出 recovery，这时 WAL sender 进程仍会不断会向从节点发送 xlog 信息。 此时，在 mirror/standby 集群中 startup 进程则不会退出，而是会通过 WAL receiver 不断地接收 xlog 信息，并在 startup 进程中进行 replay 操作。

图 5：replay 操作流程示意图

如图 5 所示，备库不断地从主库同步相应的日志数据，并在备库应用每个 WAL record，流复制每次传输 WAL 日志的 record；主库启动 WAL sender 进程，主要负责将主服务器产生的 WAL 日志记录发送给从库。

相应地，从库启动 WAL receiver 进程，与对应的 WAL sender 进程通讯，负责接收主库发送的 WAL 日志记录；同时，从库启动 startup 进程，负责将 WAL receiver 进程接收到 WAL 日志记录在从库上 replay，从而达成主从的数据同步。在 GPDB 中，默认支持同步复制，同时也支持异步复制。

示例：insert 场景下 WAL log 的变化

图 6 为在 insert(单条数据)场景下，WAL log 的变化，感兴趣的读者可以对应着图中标注的函数名来调试代码。

图 6：insert 场景下 WAL log 的变化

Custom WAL Resource Managers 特性

在此前的 PostgreSQL 版本中，rmgr 是一个静态的 enum。如果要增加新的 Resource Managers，需要在内核里去定义。

在 PostgreSQL 15 中，xlog 模块支持了 Custom WAL Resource Managers 的新改动，支持动态注册的结构，且新加了一些回调函数。

Custom WAL Resource Managers 支持外部 extension 动态添加自定义的资源类型，比如在 extension 中实现的 table access method 或 index access method。

目前，HashData 的企业级产品系列已经全面支持 PostgreSQL 15 的新特性，后续 HashData 会不断完善相关功能，进一步提升产品可用性。

总结

PostgreSQL 中的 WAL 机制的核心思想是：先日志落盘，后数据落盘。在写数据到磁盘里成为固定数据之前，先写入到日志里。