事务日志是数据库的重要组成部分，记录了数据库系统中所有更改和操作的历史信息。 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机制的核心思想是：先日志落盘，后数据落盘。在写数据到磁盘里成为固定数据之前，先写入到日志里。