postgresql wal_log日志文件堆积案例复现

项目背景

某工程中一个分系统使用了一套postgresql数据库，正常运行了大半年，前两天运维人员发现数据库使用的磁盘空间只剩15%了，因该分系统所有产生的业务数据量只保存最近一个月的，正常情况下磁盘剩余空间会维护在50%左右。现将问题排查过程记录如下:

问题分析

1、备份冗余复本删除失败了
已排除
2、接入了新数据导致数据库的数据量增加
与项目负责人沟通和对比数据库大小后，已排除。
3、调整了系统参数如wal_keep_segments,checkpoint_timeout
系统参数没有进行额外调整，因对postgresql.conf有单独备份，已排除。
4、归档操作失败
归档操作正常，已排除。
经过上面几步的排除之后，暂时没什么排查思路了，只看到pg_wal下的日志文件数超过了1.5万
5、逻辑复制订阅DISABLE（问题的根源）
后面查询postgresql进程时，发现有个logical replication launcher进程

postgres  35965  35959  0 14:27 ?        00:00:00 postgres: autovacuum launcher   
postgres  35966  35959  0 14:27 ?        00:00:00 postgres: archiver   last was 000000010000000500000038
postgres  35967  35959  0 14:27 ?        00:00:03 postgres: stats collector   
postgres  35968  35959  0 14:27 ?        00:00:00 postgres: TimescaleDB Background Worker Launcher  
**postgres  35969  35959  0 14:27 ?        00:00:00 postgres: logical replication launcher**

查看复制槽时，发现有个逻辑订阅。

postgres=# select * from pg_replication_slots;
 slot_name |  plugin  | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restar
t_lsn | confirmed_flush_lsn 
-----------+----------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------
------+---------------------
 sub_test  | pgoutput | logical   |  16384 | satdb    | f         | f      |            |      |          592 | 0/3300
0028  | 0/330000D0
(1 row)

现在基本上找到原因了，为了确认该问题，现搭建一套测试环境验证

系统环境

中标麒麟5.0+postgresql11.6
角色
发布 192.168.1.99 5432
订阅 192.168.1.99 1921
配置.pgpass
cat .pgpass
192.168.1.99:1921:replication:lineqi:lineqi
192.168.1.99:5432:replication:lineqi:lineqi
chmod 600 .pgpass
配置pg_hba.conf
cat /data/pg11/pg_hba.conf
host satdb lineqi 192.168.1.0/24 md5
配置几个关键参数
wal_level=logical
wal_keep_segments=10

场景复现

测试表
create table test(userid int,username varchar(100),crt_time timestamp(0) without time zone)
insert into test select id,‘username’||id,now() from generate_series(1,100000) as id;
alter table test add primary key(userid)
创建发布表
create publication pub_test for table test
创建订阅
create subscription sub_test connection ‘host=192.168.1.99 port=5432 dbname=satdb user=lineqi password=lineqi’ publication pub_test;
在发布节点上生成测试数据使wal_log日志文件数据超过10个
[postgres@lineqi ~]$ ls -l /data/pg11/pg_wal/|wc -l
13
在订阅节点上disable 订阅通道，在发布节点上继续执行压力测试，查询wal_log日志文件是否继续增长
insert into test select id,‘username’||id,now() from generate_series(100001,200000) as id;
[postgres@lineqi ~]$ ls -l /data/pg11/pg_wal/|wc -l
23
insert into test select id,‘username’||id,now() from generate_series(200001,500000) as id;
[postgres@lineqi ~]$ ls -l /data/pg11/pg_wal/|wc -l
36
测试结果：可以看到当订阅节点上执行disable订阅通道会导致发布节点上的wal_log日志文件不断堆积

故障处理

与相关负责人沟通后，删除disable状态的订阅通道，发布节点上的wal_log日志文件已经开始回收了

问题总结

1、没有与备份的 postgresq.conf进行详细对比，wal_level参数值发生了变化没检查出来
2、wal_keep_segments保留的日志文件数是一个软限制，会受到大事务、逻辑订阅失效（disable或订阅库down掉）影响
3、数据库作了任何调整，需要有相应的记录。
4、postgresql11.6逻辑订阅直接truncate操作，pg10.6的版本是不支持的。

扩展思考

1、订阅通道删除失败怎么处理呢？
2、当发现pg_wal日志文件数将磁盘空间快撑爆时，有什么方式能快速释放磁盘空间呢？wal_log日志可以直接删除吗？直接删除后有什么影响呢？
3、订阅通道建立时是否可以跳过发布端中的原始数据呢？