【赵渝强老师】PostgreSQL数据库的WAL日志与数据写入的过程

本文涉及的产品
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS SQL Server,基础系列 2核4GB
简介: PostgreSQL中的WAL(预写日志)是保证数据完整性的关键技术。在数据修改前,系统会先将日志写入WAL,确保宕机时可通过日志恢复数据。它减少了磁盘I/O,提升了性能,并支持手动切换日志文件。WAL文件默认存储在pg_wal目录下,采用16进制命名规则。此外,PostgreSQL提供pg_waldump工具解析日志内容。

副本_副本_副本_副本_副本_副本_副本_副本_副本_副本_副本_副本_副本_Oracle-课程封面__2025-08-11+20_34_37.png

PostgreSQL中的WAL是Write Ahead Logging的缩写,即预写日志,它是保证数据完整性的一种标准方法。简单来说就是在PostgreSQL数据库中要对数据文件进行修改时必须先写入WAL日志信息,即当WAL日志记录完成了持久化,刷新到永久储存之后才能更改数据文件。根据这个原则就不需要在每次提交事务的时候都刷新数据到磁盘。因为当数据库出现宕机发生数据丢失时,可以重新执行WAL日志来达到恢复数据库的目的。因此WAL日志也可以叫做redo重做日志,因为任何没有写到数据文件上的改动都可以根据日志记录进行重做。在默认的情况下,单个WAL预写日志文件的大小是16M,通过参数wal_segment_size决定。


postgres=# show wal_segment_size;
 wal_segment_size 
------------------
 16MB
(1 row)

# 源码安装编译的时候可以通过指定下面的参数更改其大小:
./configure --with-wal-segsize=target_value


在默认情况下,WAL日志保存在pg_wal目录下,例如:

[postgres@mydb pg_wal]$ pwd
/home/postgres/training/pgsql/data/pg_wal
[postgres@mydb pg_wal]$ tree
.
├── 000000010000000000000001
└── archive_status


WAL日志文件名称为16进制的24个字符组成,每8个字符一组,每组的意义如下:

00000001  00000000  00000001
时间线    逻辑ID      物理ID


当一个WAL预写日志文件写满时会自动切换到下一个WAL预写日志文件,而WAL切换的方式也可以是手动切换。例如,当执行pg_switch_wal()后WAL会切换到新的日志。下面展示了操作的过程:

-- 查看当前已有的WAL日志文件
postgres=# select * from pg_ls_waldir();
           name           |   size   |      modification      
--------------------------+----------+------------------------
 000000010000000000000001 | 16777216 | 2025-07-20 22:04:53+08
(1 row)

-- 进行WAL的手动切换
postgres=# select pg_switch_wal();
 pg_switch_wal 
---------------
 0/15BADD0
(1 row)

-- 再次查看当前已有的WAL日志文件
postgres=# select * from pg_ls_waldir();
           name           |   size   |      modification      
--------------------------+----------+------------------------
 000000010000000000000001 | 16777216 | 2025-07-20 22:06:31+08
 000000010000000000000002 | 16777216 | 2025-07-20 22:06:31+08
(2 rows)


通过查看pg_wal目录,此时将生成一个新的WAL日志文件:

[postgres@mydb pg_wal]$ tree
.
├── 000000010000000000000001
├── 000000010000000000000002
└── archive_status
1 directory, 2 files


PostgreSQL数据库使用WAL优势主要有以下两个方面:

  • 首先,由于在数据库数据发生变更时会先将WAL日志缓冲区中的重做日志写入磁盘,因此即使在数据库发生宕机时,数据缓冲区中的数据还没有全部写入到永久存储中的情况下,也可以通过磁盘上的WAL日志信息来恢复数据库丢失的数据;
  • 其次,在提交事务操作时仅仅是把WAL日志写入到磁盘上,并不会将数据刷新到磁盘。因此,从I/O次数来说,刷新WAL日志的次数要比刷新数据文件的次数少得多;从IO花销来说,WAL刷新是连续I/O,而数据刷新是随机I/O,因此,WAL刷新花销小得多。


WAL机制在保证事务持久性和数据完整性的同时,成功地提升了系统性能。下图说明了数据提交与WAL日志写入时的关系。

image.png


视频讲解如下:


在postgresql.conf文件中关于WAL的配置参数主要有以下几个:

wal_level = replica
fsync = on
max_wal_size = 1GB
min_wal_size = 80MB

# 其中:
# wal_level参数的可选的值有以下三个,级别依次增高,记录的WAL信息也越多。
# (1)minimal:不能通过基础备份和WAL日志恢复数据库。
# (2)replica:该级别支持WAL归档和复制。
# (3)logical:在replica级别的基础上添加了支持逻辑解码所需的信息。
#
# fsync:强制同步来实现数据安全保证。

# 当WAL日志文件的大小超过max_wal_size参数设置时,将发生WAL日志信息的覆盖,
# 从而造成日志信息的丢失。因此为了保证数据的安全,建议在生产环境中开启WAL的归档模式。


由于WAL日志文件采用了二进制的形式存储日志信息,因此PostgreSQL提供了工具pg_waldump帮助获取WAL日志文件中记录的日志信息,例如:

[postgres@mydb pgsql]$ pwd
/home/postgres/training/pgsql
[postgres@mydb pgsql]$ bin/pg_waldump \
> data/pg_wal/000000010000000000000002

# 输出的信息如下:
rmgr: Standby     len (rec/tot):     50/    50, tx:          0, lsn: 0/02000028, prev 0/015BADB8, desc: RUNNING_XACTS nextXid 485 latestCompletedXid 484 oldestRunningXid 485
rmgr: Standby     len (rec/tot):     50/    50, tx:          0, lsn: 0/02000060, prev 0/02000028, desc: RUNNING_XACTS nextXid 485 latestCompletedXid 484 oldestRunningXid 485
rmgr: XLOG        len (rec/tot):    114/   114, tx:          0, lsn: 0/02000098, prev 0/02000060, desc: CHECKPOINT_ONLINE redo 0/2000060; tli 1; prev tli 1; fpw true; xid 0:485; oid 13581; multi 1; offset 0; oldest xid 478 in DB 1; oldest multi 1 in DB 1; oldest/newest commit timestamp xid: 0/0; oldest running xid 485; online
rmgr: Standby     len (rec/tot):     50/    50, tx:          0, lsn: 0/02000110, prev 0/02000098, desc: RUNNING_XACTS nextXid 485 latestCompletedXid 484 oldestRunningXid 485




相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍如何基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
2月前
|
存储 JSON 关系型数据库
【干货满满】解密 API 数据解析:从 JSON 到数据库存储的完整流程
本文详解电商API开发中JSON数据解析与数据库存储的全流程,涵盖数据提取、清洗、转换及优化策略,结合Python实战代码与主流数据库方案,助开发者构建高效、可靠的数据处理管道。
|
15天前
|
存储 数据管理 数据库
数据字典是什么?和数据库、数据仓库有什么关系?
在数据处理中,你是否常困惑于字段含义、指标计算或数据来源?数据字典正是解答这些问题的关键工具,它清晰定义数据的名称、类型、来源、计算方式等,服务于开发者、分析师和数据管理者。本文详解数据字典的定义、组成及其与数据库、数据仓库的关系,助你夯实数据基础。
数据字典是什么?和数据库、数据仓库有什么关系?
|
4月前
|
存储 缓存 Apache
StarRocks+Paimon 落地阿里日志采集:万亿级实时数据秒级查询
本文介绍了阿里集团A+流量分析平台的日志查询优化方案,针对万亿级日志数据的写入与查询挑战,提出基于Flink、Paimon和StarRocks的技术架构。通过Paimon存储日志数据,结合StarRocks高效计算能力,实现秒级查询性能。具体包括分桶表设计、数据缓存优化及文件大小控制等措施,解决高并发、大数据量下的查询效率问题。最终,日志查询耗时从分钟级降至秒级,显著提升业务响应速度,并为未来更低存储成本、更高性能及更多业务场景覆盖奠定基础。
|
5月前
|
存储 缓存 数据库
数据库数据删除策略:硬删除vs软删除的最佳实践指南
在项目开发中,“删除”操作常见但方式多样,主要分为硬删除与软删除。硬删除直接从数据库移除数据,操作简单、高效,但不可恢复;适用于临时或敏感数据。软删除通过标记字段保留数据,支持恢复和审计,但增加查询复杂度与数据量;适合需追踪历史或可恢复的场景。两者各有优劣,实际开发中常结合使用以满足不同需求。
362 4
|
26天前
|
数据采集 运维 监控
|
5月前
|
SQL 监控 数据挖掘
SLS 重磅升级:超大规模数据实现完全精确分析
SLS 全新推出的「SQL 完全精确」模式,通过“限”与“换”的策略切换,在快速分析与精确计算之间实现平衡,满足用户对于超大数据规模分析结果精确的刚性需求。标志着其在超大规模日志数据分析领域再次迈出了重要的一步。
468 117
|
3月前
|
存储 NoSQL MongoDB
Docker中安装MongoDB并配置数据、日志、配置文件持久化。
现在,你有了一个运行在Docker中的MongoDB,它拥有自己的小空间,对高楼大厦的崩塌视而不见(会话丢失和数据不持久化的问题)。这个MongoDB的数据、日志、配置文件都会妥妥地保存在你为它精心准备的地方,天旋地转,它也不会失去一丁点儿宝贵的记忆(即使在容器重启后)。
318 4
|
3月前
|
存储 SQL Java
数据存储使用文件还是数据库,哪个更合适?
数据库和文件系统各有优劣:数据库读写性能较低、结构 rigid,但具备计算能力和数据一致性保障;文件系统灵活易管理、读写高效,但缺乏计算能力且无法保证一致性。针对仅需高效存储与灵活管理的场景,文件系统更优,但其计算短板可通过开源工具 SPL(Structured Process Language)弥补。SPL 提供独立计算语法及高性能文件格式(如集文件、组表),支持复杂计算与多源混合查询,甚至可替代数据仓库。此外,SPL 易集成、支持热切换,大幅提升开发运维效率,是后数据库时代文件存储的理想补充方案。