一、问题描述

主库WAL积压400多G，从实例启动(4月19日)到当前(8月16日)WAL就没有清理过,逻辑复制槽idcsync_8 restart_lsn 不推进；

二、分析过程

以下信息非故障实例

[postgres@ycdb pg_wal]$ pg_controldata
pg_control version number: 1201
Catalog version number: 201909212
Database system identifier: 6873258282343781547
Database cluster state: in production
pg_control last modified: Sat 6 Aug 2022 10:13:45 PM CST
Latest checkpoint location: DC/C0D974F0
Latest checkpoint's REDO location: DC/C0D974B8
Latest checkpoint's REDO WAL file: 00000001000000DC000000C0
这里表示DC/C0D974B8检查点已经执行，已经包含在00000001000000DC000000C0日志文件中，那么这个日志之前的日志是可以清理的。

如果开启了归档，在目录archive_status下会有一些文件，以ready结尾的，表示可以归档但还没有归档，done结尾的表示已经归档，对已经归档的wal，就会被自动删除。

什么情况下会自动清理wal？
1.做检查点的时候(自动或人工)

与检查点相关参数：

a）checkpoint_timeout

     系统自动执行checkpoint之间的最大时间间隔，系统默认值是5分钟。

b）max_wal_size

     在自动WAL检查点使得WAL增长到最大空间，到了这个空间，检查点 checkpoint就开始工作。

c）min_wal_size

     WAL 磁盘用量保持在这个设置之下，在检查点时旧的 WAL 文件总是被回收以便未来使用，而不是直接被删除；用来确保有足够的 WAL 空间被保留来应付WAL 使用的高峰。

d）checkpoint_completion_target

      表示checkpoint的完成时间占两次checkpoint时间间隔的比例(0-1)；设置的越高的情况下，写入速度(要求)越低，对客户端体验越好，性能越高。反之，较低的值可能会引起I/O峰值，可能导致“卡死”的现象。

2.数据库启动的时候或者修改了相关参数后重启数据库

数据库关闭：当数据库正常关闭时，会触发一次 checkpoint 。

基础备份：当进行数据基础备份时，会执行pg_start_backup命令，触发 checkpoint。

数据库崩溃修复：数据库异常退出后，比如数据库进程被kill -9，来不及清理操作 ，在重新启动时，会进行崩溃修复，修复完成后会触发 checkpoint。

什么情况下不会自动清理wal？

使用Replication Slot技术,该技术是为了避免出现"主库的xlog还未复制到备库，就被checkpoint删除"的问题；复制槽来避免主库在所有的备库收到WAL日志之前不会移除它们，即使备库断开也是一样。

pg_receivewal使用物理复制槽backup_746065*进行了实时日志备份，此物理复制槽restart_lsn处于正常位置；

idcsync_inc使用逻辑复制槽idcsync_8进行发布订阅，restart_lsn处于开始位置，一直未更新；查看idc同步结果：每天都有订阅到数据更新记录，订阅的数据无问题；但是主库上复制信息(flush_lsn,reply_time没有更新，存在异常)

原因推测：idcsync中间件工具订阅更新机制没有应答机制反馈给主库，导致主库逻辑复制槽flush_lsn,reply_time异常，所有没有推进restart_lsn，一直保留着所有的wal日志。

三、解决办法

临时解决办法：定时任务停止idc同步进程&drop 逻辑复制槽；过段几分钟后再启动idc同步进程重新开始同步。

根本解决办法：需要开发idcsync中间件开发人员排查订阅反馈机制。

四、总结

Replication Slot技术可以保证复制数据安全，但是也能由于异常导致WAL积压严重。