一站式网页设计服务平台,网页设计公司的目标客户有哪些,h5网站快速搭建,企业为什么要创新事务日志是数据库的重要组成部分#xff0c;记录了数据库系统中所有更改和操作的历史信息。 WAL log(Write Ahead Logging)也被称为xlog#xff0c;是事务日志的一种#xff0c;也是关系数据库系统中用于保证数据一致性和事务完整性的一系列技术#xff0c;在数据库恢复、高…事务日志是数据库的重要组成部分记录了数据库系统中所有更改和操作的历史信息。 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实现的需求点也有所区别主要体现在四个方面
首先是格式一般由metadata两个部分组成。meta部分记录了关联资源的元信息data是资源自定的裸数据。meta和data可以分开存储也可以统一存储。分开存储时单条WAL log需要先读取完整的meta再按需求解data统一存储时可以一条条解。举个例子在分开存储时数据组成往往是meta1meta2.. metaNdata1data2...dataN而在统一存储时数据组成往往是meta1data1meta2data2...metaNdataN。其次在修改数据时有undo log和redo log两种方式。undo log从后往前写redo log从前往后写。PostgreSQL采用的是redo log。此外循环校验码信息CRC分为完整数据和分段数据两种。分段CRC的优点是当出现错误时能够快速定位到坏的块数据且损坏的范围很小但代价是速度较慢相比之下完整数据的CRC读写速度更快但如果单个meta损坏则可能导致整个WAL log都损坏恢复成本较高。最后是否需要落盘这主要取决于具体场景如果只做同步和备份可以考虑不落盘。
WAL log的组成
在PostgreSQL中WAL log由头部、块头部、块私有数据块、自定义资源数据块四部分组成。 图3PostgreSQL中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进行恢复操作。 图4recovery流程示意图
在联机场景下primary/master集群完成数据恢复后会退出recovery这时WAL sender进程仍会不断会向从节点发送xlog信息。 此时在mirror/standby集群中 startup进程则不会退出而是会通过WAL receiver不断地接收xlog信息并在startup进程中进行replay操作。 图5replay操作流程示意图
如图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的变化感兴趣的读者可以对应着图中标注的函数名来调试代码。 图6insert场景下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机制的核心思想是先日志落盘后数据落盘。在写数据到磁盘里成为固定数据之前先写入到日志里。
