共计 3051 个字符，预计需要花费 8 分钟才能阅读完成。
事务日志是数据库的重要组成部分，记录了数据库系统中所有更改和操作的历史信息。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 机制的核心思想是：先日志落盘，后数据落盘。在写数据到磁盘里成为固定数据之前，先写入到日志里。
