1 问题现象

在GaussDB数据库运行过程中，会出现大量日志，既有保证数据库安全可靠的wal日志（预写式日志，也称为Xlog），也有用于数据库日常维护的运行和操作日志等。在数据库发生故障时，可以参考这些日志进行问题定位和数据库恢复的操作。在这篇文章中详细讲述wal相关内容与演示日志回收几个参数设置。

2 技术背景

预写式日志wal（Write Ahead Log，也称为Xlog）是指如果要修改数据文件，必须是在这些修改操作已经记录到日志文件之后才能进行修改，即在描述这些变化的日志记录刷新到永久存储器之后。在系统崩溃时，可以使用wal日志对GaussDB数据库进行恢复操作。

为了避免随机I/O写性能过低的情况，会先将事务的数据库修改写入一个顺序追加的wal日志文件中，由于写日志文件是顺序I/O操作，可以达到一个很高的性能。

当系统崩溃发生时，数据库可以通过日志中记录的数据变化恢复系统崩溃前的操作。在日志回放的过程中，数据库会根据日志记录的先后顺序，依次读取每个日志的内容，然后判断该日志记录的事务对数据库数据文件的修改是否和当前相关数据文件的内容一致。如果一致，说明数据库停机之前的修改已经写入数据文件中，该日志修改无须回放；如果不一致，则说明数据库停机之前的修改还没有写入数据文件中，上次数据库停机可以是异常宕机导致，该日志对应的事务操作需要重新在相关数据文件中执行，才能保证恢复成功。

wal日志实际默认被划分为16M大小的一系列文件，这些文件默认存储在数据目录的pg_xlog子目录下，被称为wal段（WAL Segment），Checkpoint线程将日志数据写入到WAL BUFFER中，由后台wal日志线程异步刷盘。

其中，Checkpoint是wal日志中的一个位点，在这个点位之前数据库中的所有数据和wal中反映的信息相同（即可以认为这个点位前的数据已经落盘到数据文件中了）。Checkpoint也是一个操作，这个操作会往wal日志里写checkpoint位点。主要作用：

   1、记录redo point，标记redo point之前的数据均已刷脏，完成持久化存储；

    2、标记redo point之前的wal日志可以被清理加收；

    3、脏页刷盘

GaussDB数据库中Checkpoint分全量和增量，内部使用的是增量Checkpoint，1分钟执行1次。全量Checkpoint，Checkpoint期间会将缓存中脏页全部下刷落盘，导致I/O紧张，影响正常业务；不能频繁触发，redo推进慢时，宕机后redo的时间会变长。

对于增量Checkpoint，缓冲区脏页按顺序放到一个缓存队列，后台wal日志线程会依照顺序依次刷盘，Checkpoint根据刷页进度推进redo点；频率不受限制，及时推进，降低RTO。wal日志对数据库异常恢复有重要的作用，建议定期对WAL日志进行备份。

3 WAL日志相关参数

wal日志主要有以下几个相关参数：

其中wal_file_init_num和advance_xlog_file_num通常用在性能测试上，先初始化足够多的wal日志文件，减少I/O的占用。

一般情况下，wal日志文件数量计算公式：wal_keep_segments + checkpoint_segments * 2 + 1 (个)

4 预写日志回收文件数验证

以TPCC测试WAL日志变化

4.1 初始化数据库

使用3_nodes_centralized_1primary_1standby_1logger.json一主一备一日志模板初始安装完成数据库后， 数据库状态如下，服务器ecs-wal-test-0001为主，ecs-wal-test-0002为备，ecs-wal-test-0003为日志

wal日志信息如下

4.2 检查数据库初始参数

[omm@ecs-wal-test-0001 ~]$ gsql -dpostgres -p30100 –ar
gsql ((GaussDB Kernel 505.2.0.SPC0100 build 2450ca36) compiled at 2024-11-02 19:03:53 commit 9980 last mr 20502 release)
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.
gaussdb=# show advance_xlog_file_num;
advance_xlog_file_num
-----------------------
0
(1 row)
gaussdb=# show wal_file_init_num;
wal_file_init_num
-------------------
10
(1 row)
gaussdb=# show checkpoint_segments;
checkpoint_segments
---------------------
1024
(1 row)
gaussdb=#

4.3 修改参数限制wal日志数量

备份数据库后，修改参数，将wal日志数量调大，并重启生效。

gs_guc set -Z coordinator -Z datanode -N all -I all -c "advance_xlog_file_num = 20"
gs_guc set -Z coordinator -Z datanode -N all -I all -c "wal_file_init_num = 50"
gs_guc set -Z datanode -N all -I all -c "checkpoint_segments = 200"

重启后检查wal日志信息

从图中可以看到，主机上wal文件个数已经变成57，第一备机也增涨到35个，日志备机成了7个。

4.4 初始化tpcc库

4.4.1 创建用户和库

[omm@ecs-wal-test-0001 ~]$ gsql -dpostgres -p30100 -c "create user tpcc identified by 'huawei@123';"
CREATE ROLE
[omm@ecs-wal-test-0001 ~]$ gsql -dpostgres -p30100 -c "grant all privileges to tpcc;"
ALTER ROLE
[omm@ecs-wal-test-0001 ~]$ gsql -dpostgres -p30100 -c "create database tpcc encoding 'utf8' template=template0 owner tpcc;"
NOTICE: Since current compatibility mode is A-Format, will use templatea as default template.
CREATE DATABASE
[omm@ecs-wal-test-0001 ~]$

4.4.2 执行脚本初始化数据

4.4.3 检查wal日志

检查wal日志文件数量，可以看到在增涨。

Tpcc库数据初始化完成后，wal日志文件数量如下图

wal日志最小文件数量约为：wal_keep_segments + checkpoint_segments * 2 + 1=200*2+128+1=529

4.5 执行脚本测试预写日志最大值

[omm@ecs-wal-test-0001 run]$ nohup ./runBenchmark.sh props.gs > props_gs.log &
[1] 1584656
nohup: ignoring input and redirecting stderr to stdout

通过监控，发现有删除wal日志操作，但是日志文件总量已经不出现变化

Wal日志文件有删除和重建，注意下图中两次查询时目录下日志文件名称

wal日志文件数量

4.6 测试预写日志回收

4.6.1 修改日志回收参数

先备份数据库，再执行以下修改日志回收参数

gs_guc set -Z datanode -N all -I all -c "checkpoint_segments = 100"
gs_guc set -Z datanode -N all -I all -c "advance_xlog_file_num = 0"
gs_guc set -Z datanode -N all -I all -c "wal_file_init_num = 10"
gs_guc set -Z datanode -N all -I all -c "enable_xlog_prune ='on'"
gs_guc set -Z datanode -N all -I all -c "max_size_for_xlog_prune =2GB"
gs_guc set -Z datanode -N all -I all -c "wal_keep_segments =128"

验证以上步骤执行情况：

4.6.2 开始tpcc测试

从DN日志可以看出，有wal日志删除

监控wal日志文件数量，可以看到，日志文件在不断减少

由于配置的checkpoint_segments=100，wal_keep_segments=128，根据计算公式，日志回收阈值min = 100*2+128+1 = 329，当前目录中保留的wal日志数量为333，与回收阈值相差很小，考虑dcf等影响，该数值在正常范围。

5 总结

GaussDB预写日志文件个数设置在本文中详细地说明并做了验证，可以通过checkpoint_segments和wal_keep_segments两个参数控制，在现场环境中结合实际的业务场景合理的设置。