PG WALOG 运维

PG WALOG 运维

WALOG 是PostgreSQL的事务日志，相当于Oracle、MySQL的REDO日志。线上PostgreSQL在运行过程，可能会出现pg_wal目录中wal日志文件个数一直在增加，导致pg_wal目录大小一直在增加，直至磁盘耗尽，数据库实例宕机。

哪些情况可能引起该问题?1 开启了归档模式 archive_mode=on，但是archive_command归档命令未设置或没有执行成功2 存在没有使用的复制槽，导致pg_wal文件一直增加不回收3 参数max_keep_segments/max_keep_size 设置不合理

相关的WAL参数1 Wal_segment_size:单个WAL段文件大小，默认16MB，11版本之前在编译时指定，11版本之后，在数据库初始化时指定2  Wal_keep_segments:standby复制所需的在pg_wal目录中最少保留的wal文件个数，如果为0取决下面两个参数的设置      Min_wal_size：wal文件保留的最小大小，当低于该参数值时，触发checkpoint时以回收的方式处理wal文件   Max_wal_size：指定两次checkpoint之间产生的wal大小，配合checkpoint_timeout触发checkpoint3  Archive_timeout:达到archive_timeout时，触发一次wal文件切换，如果设置过小，导致在空闲实例上积累大量的归档日志4 Max_slot_wal_keep_size:该参数控制每个复制槽可以保留的wal日志大小，默认为0都保留

问题分析1  开起归档，但是归档命令失败：archive command failed with exit code

The failed archive command was:.....NO such file or directory

归档命令在执行过程中报错，归档失败，导致WAL文件无法正常归档，在进行CHECKPOINT时，无法回收，久而久之导致pg_wal目录大小一直增加。通过视图pg_stat_archiver可以查看归档失败的次数，已经最后一次归档的日志文件：

PigSql>select * from pg_stat_archiver;+-----------------+--------------------+--------------+--------------------+--------------------+---------------------+| archvied_count  | last_archived_wal  | failed_count |  last_failed_wal    |  last_failed_time   |  starts_reset        |+---------------------------------------------------------------------------------------------------------------------+|             100  |            NULL     |     250       |   0000001000000003E|  2019-03-08 16:47:08| 2019-03-08 16:48:03|+----------------------------------------------------------------------------------------------------------------------

将归档命令调整正常归档后，重新加载配置文件进行生效。手工触发checkpoint将较早的WAL日志文件回收。

2 复制槽PostgreSQL在异步流复制环境，如果STANDBY库宕机，经过一段时间后重新启动，可能需要的WAL日志文件在主库已经被回收，导致备库无法和主库建立保持同步。报错如下：

could not receive data from WAL stream FATAL:requestd WALsegment...has already been removed为了解决该问题，PG引入了复制槽，如果STANDBY备库意外宕机，其需要的WAL文件，则会一直保留的pg_wal目录中，直到STANDBY状态正常追上MASTER。在STANDBY宕机的时间段内，WAL日志则一直不回收，导致pg_wal目录大小一直增加。查看复制槽状态：

PigSql>select * from PG_REPLICATION_SLOTS;---[ RECODE  10] ----------+-------------SLOT_NAME                  | PG_SLOT_TEST PLUGINSLOT_TYPE                  | PHYSICALDATOIDDATABASETEMPORYAY                   | FACTIVE                      | F ACTIVE_PIDXMINCATALOG_XMINRESTART_LSN |0/C000001CONFIRMED FLUSH LSN

如果active状态为f，表示该复制槽未使用。然后确认restart_lsn对应的文件名：

PigSql>SELECT PG_WALFILE_NAME('0/C000001');-[RECODE 10 ]------+---------------------------PG_WALFILE_NAME    |00000000000010000000000B

在和pg_wal目录中最早的wal文件进行对比，可以发现该文件是最早创建的。因此引起pg_wal目录暴涨的原因就是该复制槽引起，将该复制槽删除后，手工执行checkpoint就可以将较早的WAL段文件进行回收。

3 参数max_keep_segments/max_keep_size设置不合理在不使用复制槽的情况，PG也提供了一种解决方案在一定程度上可以防止STANDBY意外宕机重启后无法和MASTER保持同步。Max_keep_segments在主库最多保留这么wal日志文件用于STANDBY同步使用，当WAL文件个数超过该参数设置后，同样会触发WAL日志回收。PG默认的WAL段文件大小为16MB，如果该参数设置的较大，则会占用较多的磁盘空间。在WAL文件个数未达到上限时文件不会回收，pg_wal的目录大小会一直增加。

解决办法3。1 做好数据库监控及时发现存在的不安全隐患，针对本文，需要监控归档是否成功，是否存在无用的复制槽3.2  针对复制槽在PG13版本新增加了一个参数max_slot_wal_keep_size控制每个复制槽可以保留的WAL文件的大小，超过该大小，较早的WAL日志回收。3.4 根据线上环境设置合理的max_keep_segments/max_keep_size参数，避免pg_wal目录过大