xlog（WAL）堆积问题总体排查思路
问题描述
xlog（WAL）堆积，明显超过预期大小，导致磁盘空间使用率上涨，甚至打满磁盘，影响实例运行。
可能影响
- 占用更多的磁盘空间；
- 可能会打满磁盘，影响实例运行。
解决步骤
- 首先检查WAL和归档相关参数，核实参数是否符合预期；
连接到WAL日志堆积的节点，执行以下SQL：
select current_setting('wal_keep_segments') as wal_keep_segments,(select count(1) from pg_ls_dir('./pg_wal/')) as wal_count;
WAL相关参数中，wal_keep_segments为保留WAL日志文件的数量，通常实际统计的WAL日志文件数量比wal_keep_segments稍多，相差几百内都属于正常范围，明显超出则确定WAL日志有堆积；
- 检查WAL日志增长量是否符合预期；
登录WAL日志堆积的节点所在服务器，进入pg_wal目录，执行以下shell命令，按纬度统计WAL数量；
统计每小时日志数量
ls -lrt |egrep [0-9A-Z]{16}|awk '{print $6" "$7" "$8}'|awk -F: '{print $1}'|sort |uniq -c
统计每天日志数量
ls -lrt |egrep [0-9A-Z]{16}|awk '{print $6" "$7}'|awk -F: '{print $1}'|sort |uniq -c
- 检查复制槽状态，是否有active=false的复制槽；
连接到WAL日志堆积的节点，执行以下SQL：
select * from pg_replication_slots where active=false;
如果有active=false的复制槽，那么就会导致WAL堆积，需要核实并解决复制槽问题；
- 如果不是复制槽问题，可以继续检查归档配置是否正确；
连接到WAL日志堆积的节点，执行以下SQL：
show archive_status_control;
如果参数查询结果为break，那么WAL日志文件不会被正常删除，需要核实并更正参数为continue；
- 检查归档执行状态是否正常；
登录WAL日志堆积的节点所在服务器，检查archiver进程状态是否正常，进程显示的last 归档的文件是否在更新。
ps -fe|grep archiver
查询结果显示为archiver process failed on xxx，则说明归档败了，需要进一步排查归档失败原因；
也可以执行以下SQL查询归档执行状：
select * from pg_stat_get_archiver();
其中failed_count>0表示有归档失败。
- 检查归档速度是否正常；
如果归档正常，那需要检查归档速度是否正常，归档速度是否能赶上WAL日志生成的速度，如果归档速度比生成的慢，那么WAL日志会逐渐堆积起来，可以从减少WAL日志生成量和加快WAL日志文件归档两个方面入手进行优化；
- 检查是否有长事务/长时间执行未结束的SQL；
连接到WAL日志堆积的节点，执行以下SQL：
select pid,client_addr,state_change,query_start,state_change,EXTRACT(EPOCH FROM (now()-query_start)),query,state,usename,application_name from pg_stat_activity where EXTRACT(EPOCH FROM (now()-query_start))>600 and state!='idle';
如果有长时间执行未结束的SQL或事务，需要核实后清理掉，避免影响WAL日志文件的清理。
- 如果影响业务，需要快速恢复，可以先手动清理，再定位原因；
登录WAL日志堆积的节点所在服务器，进入pg_wal/archive_status目录，执行以下shell命令，修改*.ready 的扩展名称*.done
find *.ready | sed 's/.ready$//'| xargs -I {} mv {}.ready {}.done
或
ls -lrt | grep .ready | awk -F' ' '{print $NF}' | xargs -i rename ready done ./{}
如果提示有太多的bash: /usr/bin/find: Argument list too long，则需要分批修改，具体前缀可以 top看一下 Arichve 进程当前在处理哪个WAL，然后取其前缀就行，例如：
find 00000001000005[1-9]*.ready | sed 's/.ready$//'| xargs -I {} mv {}.ready {}.done
find 00000001000005[A-F]*.ready | sed 's/.ready$//'| xargs -I {} mv {}.ready {}.done
复制槽状态为false导致xlog（WAL）堆积问题
问题描述
复制槽状态为false，导致xlog（WAL）堆积。
连接到WAL日志堆积的节点，执行以下SQL，返回结果有active=false的复制槽：
select * from pg_replication_slots where active=false;
可能影响
- 占用更多的磁盘空间；
- 可能会打满磁盘，影响实例运行。
解决步骤
- 需要先核实复制槽哪个应用哪些场景下使用的，并评估是否可以删除；
- 如果可以删除，需要评估并给出删除方案，由于使用场景不明确，不建议直接执行以下删除命令；
select pg_drop_replication_slot('xxx');
- 参考删除方案执行。
归档失败导致xlog（WAL）堆积问题
问题描述
归档失败，导致xlog（WAL）堆积。
检查archiver进程状态，显示查询结果显示为archiver process failed on xxx。
ps -fe|grep archiver
或执行以下SQL查询归档执行状态，failed_count>0且持续增长，表示归档失败。
select * from pg_stat_get_archiver();
可能影响
- 占用更多的磁盘空间；
- 可能会打满磁盘，影响实例运行。
解决步骤
- 检查备份介质是否可以正常访问，正常上传文件，检查上传文件速度是否正常；
- 常见问题如：
1）环境变更，部分服务器上备份介质客户端未安装或配置错误，导致备份介质不能访问；解决办法：可通过手动执行访问介质命令进行验证，命令需要和备份任务中命令保持一致，避免因命令不同导致验证结果不准确；如有问题需检查环境并进行修复；
2）备份介质环境原因，介质环境故障、空间打满、网络中断等原因，导致服务器不能访问备份介质；
解决办法：可通过检查备份介质环境，包括是否可访问，是否有足够的空闲资源，访问和上传文件速度是否正常；如有问题需修复备份介质环境；
3）可能由于备份任务自身原因导致，例如备份任务有bug，导致备份失败，如核实有此问题，及时反馈TeleDB产品团队进行核实修复。
