PostgreSQL中wal日志具备幂等性吗？

最新推荐文章于 2025-07-01 09:28:51 发布
原创 最新推荐文章于 2025-07-01 09:28:51 发布 · 1.8k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#数据库 #sql #postgresql

本文探讨了PostgreSQL的WAL日志与Oracle的redo日志在幂等性方面的差异。尽管WAL日志在结构上类似于具有幂等性的生理日志，但非备份区块的幂等性是通过跳过已应用的记录来实现的。PostgreSQL通过比较LSN来决定是否重播日志，从而确保了幂等性。总结来说，PostgreSQL的wal日志是具备幂等性的。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

数据库日志与幂等性

最近在看《The Internals of PostgreSQL》这本书时发现这样一段话：
In short, the redo (replay) operation of non-backup block is not idempotent. Therefore, to preserve the correct replaying order, non-backup block records should replay if and only if its LSN is greater than the corresponding page’s pd_lsn.
On the other hand, as the redo operation of backup block is idempotent, backup blocks can be replayed any number of times regardless of its LSN.

看到这句话我感觉还是挺奇怪的，PG的wal日志的非备份区块竟然不具备幂等性，而与之类似的例如Oracle中的redo我们都知道是幂等的，难道PG的wal日志并不是这样的吗？

这里简单说明下什么是幂等性。在数学上，幂等元素是指被自己重复运算(或对于函数是为复合)的结果等于它自己的元素。而对于数据库的日志而言指的便是该日志可以重复回放多次且结果仍然相同。

那么为什么Oracle的redo日志就是具有幂等性呢，而像我们熟悉的MySQL的binlog就是不具备幂等性的，这又是为什么呢？主要还是因为前者是物理日志而后者是逻辑日志。

物理日志与逻辑日志

物理日志与逻辑日志在存储内容上有很大的区别，存储内容是区分它们的最重要手段。

  • 物理日志：

存储数据库中特定记录的变更，通常是 page oriented，即描述具体某一个 page 的修改操作。例如存放一个page修改前的状态和修改后的状态。

  • 逻辑日志：

存储事务中的一个操作。例如insert、update、delete等。

下面我们来详细说明下它们之间的区别。

Physical Logging

在这里插入图片描述
以上图为例，我们对Page42进行update，将字段 “Kemera” 修改为 “camera”。更新操作对应的日志大致为：

"Page 42:image at 367,2; before:'ke';after:'ca'"
  • Page 42 用于说明更新操作作用的 page；
  • 367：用于说明更新操作相对于 page 的 offset；
  • 2：用于说明更新操作的作用长度，即 length，2 代表仅仅修改了两个字符；
  • before:‘Ke’：这里表示 undo information，也可以称为 undo log；
  • after:‘ca’：这里表示 redo log information，也可以称为 redo log；

可以看到物理日志中存储的主要就是某条记录对应的page的状态变化，那么自然是具有幂等性的，因为无论应用多少次，最终的状态总是一样的。

Logical Logging

在这里插入图片描述
上图中表示将CameraLingo表中itermID为0处的“Kemera” 修改为 “Cemera“，其对应的日志大致为：

CameraLingo:update(0,'Kermera'=>'camera')

在逻辑日志中就没有存储page的修改了，而存储的是类似于一条SQL语句，所以不需要指定物理上的某个page，而只是指定逻辑上的某张表即可。
这样有一个巨大的优势便是，如果我们一条SQL语句对大量的page进行了修改，那么逻辑日志的数据量相对于物理日志便会小很多。

而除此之外，还有一种具备物理日志和逻辑日志特点的日志，Physiological Logging。

Physiological Logging

在这里插入图片描述
Physiological Logging 的格式类似如下：

（Page ID，Record Offset，(Filed 1, Value 1) … (Filed i, Value i) … )

其中，Page ID、Record Offset 的设计源于物理日志。(Field1,Value1) 的设计来源于逻辑日志。

Physiological Logging 的特点是：

  • 与物理日志相同，更新操作相对于 page 进行，每一条日志仅仅涉及一个 page 的修改；
  • 与逻辑日志相同：日志内容为更新语句（update query）本身，而不是状态机某些字段更新前后的状态。

可以发现Physiological日志兼具了逻辑日志数据量小和物理日志幂等性的特点。

PostgreSQL中WAL日志幂等性

介绍了主要的日志形式，那么我们来看看PostgreSQL中wal日志是哪张类型的，为什么又说其不具备幂等性呢？

WAL日志格式

以一个简单的wal日志举例：
rmgr: Heap len (rec/tot): 65/ 177, tx: 717, lsn: 1/92021450, prev 1/92021418, desc: HOT_UPDATE off 1 xmax 717 flags 0x20 ; new off 2 xmax 0, blkref #0: rel 1663/16395/17623 blk 0 FPW

  • rmgr: Heap ：PostgreSQL内部将WAL日志归类到20多种不同的资源管理器。这条WAL记录所属资源管理器为
    Heap,即堆表。除了Heap还有Btree,Transaction等。
  • len (rec/tot): 65/ 177：wal记录的长度。
  • tx: 717： 事务号。
  • lsn: 1/92021450：本条wal记录的lsn。
  • prev 1/92021418：上条wal记录的lsn。
  • desc: HOT_UPDATE off 1 xmax 717 flags 0x20 ; new off 2 xmax 0：
    这是一条热更新类型的记录，旧数据
  • offset为1，xmax为717。旧tuple在page中的位置为1(即ctid的后半部分)，新tuple在page中的位置为2。
  • blkref #0: rel 1663/16395/17623 blk 0
    ：引用的第一个page(新tuple所在page)所属的堆表文件为1663/13543/16469,块号为0(即ctid的前半部分)。

可以看出wal日志是类似于Physiological日志的，既有Page ID、Record Offset这些信息，也有记录数据修改类型操作的记录。而对于这些操作的回放，PostgreSQL中是通过资源管理器进行实现的。

以PG10为例，有以下几种类型的资源管理器：
在这里插入图片描述

WAL日志的回放

以我们上面这条WAL日志为例，其资源管理器为 Heap，那么对这条日志进行回放的大致流程为：

  1. 读取到该日志，解析日志头部，根据日志的类型，将日志交由对应资源管理器回放
  2. 解析该WAL日志，根据具体的操作类型，交由具体的函数进行回放
  3. 解析WAL日志内容
  4. XLogReadBufferForRedo，读取需要修改的页面，进行PIN和LOCK操作，并根据LSN确认是否需要REDO
  5. 如果需要REDO，则将日志应用到页面上，更新页面的LSN，标记页面为脏页
  6. 对需要修改的页面进行UNPIN和UNLOCK操作，其他进程可以使用该页面，bgwriter可以向下刷该页面

下面我们结合具体的代码来看看wal日志的回放流程，来看看究竟wal日志是不是具有幂等性。

函数的调用顺序为：

StartupXLOG->heap_redo->heap_xlog_insert

而主要涉及到回放wal日志的是heap_xlog_insert。

首先我们要判断回放wal日志是不是需要重新初始化一个新的page：
在这里插入图片描述
然后要去判断wal日志的LSN和page的LSN（需要注意对于备份区块而言，不需要判断LSN而是直接全部应用）。
在这里插入图片描述
紧接着我们便可以向page中插入这条数据：
在这里插入图片描述
这便是上述一条普通数据插入的恢复流程，在恢复的过程中，并不是通过逻辑日志那种一条条SQL语句，而是通过资源管理器将操作记录进行回放。

WAL日志与幂等性

那么wal日志的恢复是不是具备幂等性呢？从上面的代码中我们可以看到，如果WAL日志记录的LSN比page中的LSN大，那么便会将WAL日志中记录的数据插入到page中，并将page的LSN更新成WAL日志的LSN。

而对于WAL日志记录的LSN比page中的LSN小的情况，是直接跳过，没有对应的处理。

那么其实PostgreSQL中的wal日志是具备幂等性的，因为我们重复应用日志得到的结果是同样的，而之所以一样是因为压根就直接跳过了，所以当然一样。

而《The Internals of PostgreSQL》中说备份区块的wal日志具备幂等性，非备份区块不具备幂等性的这种说法应该是想将两者进行对比。毕竟备份区块是会重复去应用的，得到的结果是一样的，而非备份区块是直接跳过了，并没有去应用，如果从这个角度来说似乎也是合理的。

总结

PostgreSQL中的wal日志是具备幂等性的，只是对于非备份区块而言，如果已经应用过的wal日志是会直接跳过，而并不是真正的去重新应用，因此最终的状态自然是不变的。

参考链接：
https://www.interdb.jp/pg/pgsql09.html
https://spongecaptain.cool/post/database/logicalandphicallog/#13-physiological-logging
http://mysql.taobao.org/monthly/2020/02/01/

【数据库学习】Postgres（PG）概览与PostgreSQL基本语法
午后阳光
01-27 2万+
-数组可以定义长度、也可以不给。也可以定义多维数组。但定义长度和多维数组在实际使用中是无效的。如下面两种定义是等价的。类似于C的结构体，
mysql详解之redolog的关键——幂等性
yunduanyou的博客
12-05 1246
本篇博客的前提是默认读者已经对mysql-innodb内部原理及各种概念有了比较全面的认识。过了是什么阶段，而在为什么阶段的一些深入思考（关于innoDB的基础原理概念，请期待下一篇博客）。说到redo log，我们都会说它是物理日志（和binlog的逻辑日志做对比）。但没人解释过：为什么要用物理日志。换个马甲，显得高级？很多文章在讲redo log时，好像有意无意的都在强调：redo log写日志时，顺序io带来的快或者能保住更多数据。这两点真的是redo log主要追求的东西吗？想一个问题：缓冲池是不是
Postgresql管理系列-第九章 WAL(Write Ahead Logging)介绍
魂醉的一亩二分地
07-11 3174
事务日志是数据库的重要组成部分，因为即使数据库发生系统故障，也要求所有数据库管理系统不能丢失任何数据。它是数据库系统中所有更改和操作的历史记录日志，以确保没有数据因故障而丢失，例如电源故障或导致服务器崩溃的其他服务器故障。由于日志包含有关已执行的每个事务充足的信息，因此数据库服务器应能够通过在服务器崩溃时重放事务日志中的更改和操作来恢复数据库集群。 在计算机科学领域，WAL是Write Ahead...
【PostgreSQL系列】PostgreSQL WAL 目录配置
CSDN站内信: https://i.csdn.net/#/msg/chat/qyj19920704
06-11 2567
在 PostgreSQL 数据库管理中，WAL（Write-Ahead Logging，预写式日志）是一个至关重要的组件，它不仅是数据库恢复机制的核心，也是保证数据一致性和持久性的关键技术。PostgreSQL 的 WAL 机制是一种标准的事务日志实现，它要求在数据写入磁盘前，先将变更记录写入持久化的日志中。但随着数据库规模的增长和性能需求的提高，将 WAL 目录独立出来成为一项重要的优化措施。为 WAL 目录选择合适的存储方案是数据库优化的关键环节。WAL 日志默认存储在数据目录的。参数或环境变量设置。
Postgresql——WAL(Write-AHead Logging，预写式日志）
weixin_45694422的博客
04-21 344
WAL——Write-AHead Logging，预写式日志 1.目的： 保证数据库的可靠性 2.概述 Write-AHead Logging即WAL是一套保证数据完整性的标准。简要地说，WAL中心概念是数据文件（这里涉及到表和索引）修改必须在这些动作被记录之后，即 描述这些修改操作的日志记录被刷到永久存储中。如果我们遵循这个过程，我们不需要在每次事务提交时刷数据页到磁盘，因我我们知道一旦发生崩溃...
PostgreSQL——Wal文件
cf_808的博客
07-31 1566
PostgreSQL中的WAL（Write-Ahead Logging，预写式日志）文件是数据库持久性机制的重要组成部分。
innodb 01 redo 日志详解
xizi_ghq的博客
01-10 584
redo 和binlog的区别。 1、二进制日志server层产生，redo是innodb层产生。并且binlog先于redolog被记录 2、binlog记录操作的方法是逻辑性的语句，基于行格式。redolog是innodb层产生的日志，记录数据库每个页的修改。 3、binlog是事务提交的时候，一次性写入，redolog是数据准备修改的时候写入redobuffer,然后才对缓存中数据操作。并且保证，事务提交时：redobuffer冲刷到磁盘 4、binlog是一次性写入，所以有顺序。redolog是物理
【数据一致性保证】：数据库事务管理在校园跑腿系统中的应用
结合需求分析，文章阐述了事务管理在保证数据一致性、实现业务流程中的关键作用。重点讨论了事务管理设计原则、技术选型和案例研究，以及性能优化和故障应对措施。最后，本文展望了事务管理的未来发展趋势，包括柔性...
微服务架构中的CDC实践：确保服务间数据一致性指南
然而，微服务架构中的数据一致性问题变得尤为重要，尤其是在分布式系统中，数据的实时性和准确性对用户体验至关重要。本文首先探讨了CDC（Change Data Capture，变更数据捕获）技术的概念、分类及选型依据，重点分析...
容器热升级下的数据一致性与挂载稳定性保障策略
最新发布
努力分享一些人工智能、计算机视觉、影像等相关的知识干货！
07-01 1059
在微服务架构与高可用性需求驱动下，容器热升级（Rolling Update）已成为持续部署过程的核心能力。然而，对于使用挂载卷（PVC、NFS、CSI）的有状态服务而言，热升级过程中若处理不当，极易引发数据写丢失、目录错乱或挂载崩溃等稳定性问题。本文围绕热升级场景下容器数据一致性与挂载稳定性的关键挑战，系统梳理包括挂载隔离、状态协同、并发写入防护、预热同步、就绪探针等在内的保障策略，并结合企业级实践提出可持续演进的治理方案，提升容器化平台在有状态服务演进过程中的稳定性与安全性。
PostgreSQL数据库WAL——简介
肥叔菌的博客
10-18 1477
当插入、删除等变更动作发生时，PG会生成对应动作的WAL记录，然后写入到内存中的WAL缓冲区。满足以下任意条件时，WAL记录会从缓冲区写入到段文件，以确保数据安全： 一个运行中的事务提交或中止 WAL缓冲区被写入的元组填满（WAL缓冲区大小可由参数wal_buffre控制） WalWriter周期性的执行写操作 checkpoint 当数据库进行恢复时，会从重做点开始进行恢复。重做点是指最新的checkpoint开始时WAL记录写入的位置。当数据库启动时，PG会判断是否需要进行恢复，比如数据库是在imm
PostgreSQL的WAL机制（转）
weixin_30840573的博客
07-06 231
转发来源： https://www.jianshu.com/p/a37ceed648a8 https://www.cnblogs.com/daduxiong/archive/2010/09/30/1839533.html WAL：Write-Ahead Logging 为什么进入WAL？ 持久性是指，事务提交后，对系统的影响必须是永久的，即使系统意外宕机，也必须确保事务...
PostgreSQL 的 WAL（Write-Ahead Logging）机制及其作用
My_wife_QBL的博客
08-21 1175
WAL（Write-Ahead Logging）是一种日志记录机制，用于确保数据库在发生故障时能够恢复到一致的状态。WAL 的基本思想是在对数据进行实际修改之前，先将这些修改记录到日志中。这样，在系统崩溃或其他故障发生时，数据库可以根据 WAL 中的记录进行恢复，确保数据不丢失。PostgreSQL 中的 WAL（Write-Ahead Logging）机制是保障数据持久性与一致性的重要组成部分。通过将数据修改记录到日志中，WAL 机制不仅提供了强大的故障恢复能力，还增强了系统的高可用性。
PostgreSQL数据库WAL总结
qq_58883939的博客
04-26 3677
简单地说，WAL的核心概念是，对数据文件(表和索引所在的地方)的更改必须在写入了日志文件后这些更改之后才可以写入数据文件，也就是说，描述更改的日志记录被刷新到永久存储之后才可以写数据文件。使用WAL可以显著减少磁盘写操作的数量，因为只需要将日志文件刷新到磁盘以确保提交事务，而不是事务更改的每个数据文件。日志文件是按顺序写入的，因此同步日志的成本要比刷新数据页的成本低得多。备注：数据库将脏数据刷到数据文件上,这个动作是随机I/O,性能比写日志的顺序I/O差太多总结
postgreSQL WAL简介
yunmu666的博客
02-01 331
WAL
postgresql之WAL(Write Ahead Log)
weixin_30861797的博客
09-30 526
oracle中存在重做日志文件(redo log),其作用是保证数据的一致性和事务的完整性，防止在系统崩溃时最近的事务无法恢复。在postgresql中引入了WAL(write ahead log),作用相同。有不同之处的是postgresql数据库可以通过调整WAL参数控制日志写入磁盘的先后顺序。先将日志写入磁盘能够完全保证数据的完整性，在崩溃时可以恢复最近的事务；后写入磁盘，很难保证在崩溃时事...
02-PostgreSQL的WAL机制
foshansuperinter的博客
12-08 4150
1 Debezium是如何从PostgreSQL抓取数据的 Debebzium为PostgreSQL提供了PostgreSQL Connector，它通过同步WAL记录实现从PostgreSQL抓取数据的功能。 要真正明白PostgreSQL Connector的运行原理，就必须先了解PostgreSQL的WAL机制。 2 WAL(Write-Ahead Logging, 预写式日志) WAL保存了对数据库的操作记录，保证了PostgreSQL的事务持久性和数据完整性，同时避免了频繁的io对数据库性能的影响
PostgreSQL DBA(15) - WAL文件结构
12-17 435
数据库的历史变更会持久化到事务日志文件中，本节简单介绍了PG中事务日志文件的体系结构（以下简称WAL文件结构）。 一、WAL文件结构 PG使用无符号64bit整型（uint64）作为日志文件的寻址空间，...
深入解析PostgreSQL的wal2json日志工具
2. WAL（Write-Ahead Logging）日志: PostgreSQL使用WAL来保证数据的完整性，它会在事务提交之前，将事务日志写入到日志文件中。WAL在数据库系统中起着至关重要的作用，比如在发生故障时进行恢复，以及在实现复制时...
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值