ALM-5101339 Ops巡检-xlog数量异常

告警解释

此告警对应指标“xlog数量”超出配置阈值，此指标反映组件保留的xlog数量。

告警属性

告警ID	告警级别	告警类型	告警归属	业务类型	是否可自动清除
5101339	巡检配置	业务质量告警	租户面	云数据库 GaussDB 节点	是

告警参数

类别	参数名称	参数含义
定位信息	云服务	产生告警的云服务
	实例ID	产生告警的实例ID
	节点ID	产生告警的节点ID
	巡检名称	产生告警的巡检名称
	指标编码	产生告警的指标编码
附加信息	租户名称	产生告警的租户名称
	实例名称	产生告警的实例名称
	租户ID	产生告警的租户ID
	云服务	产生告警的云服务
	服务	产生告警的服务
	微服务	产生告警的微服务
	告警源IP	告警源IP
	节点角色	产生告警节点的节点角色
	指标编码	产生告警节点的指标编码
	指标采集值	产生告警节点的指标采集值
	指标阈值	产生告警节点的指标阈值

对系统的影响

通常情况下不会上涨。如果持续上涨，磁盘空间会异常占用，严重时磁盘可能只读。

可能原因

xlog相关参数配置使得未达到回收的条件。
运维操作约束，执行期间xlog不回收。
逻辑复制槽占用。
delay_xlog_recycle文件残留。
业务数据持续写入，xlog回收速率无法追赶上生成速率。

处理步骤

收到告警后，首先通过查看监控指标查看指标“xlog数量”，确认指标情况以及触发告警的组件。
同步查看告警组件“集群数据磁盘已使用百分比(sum(DN)/副本数)”指标。
- 如果指标值已经接近85%，通过修改实例参数查看只读阈值参数datastorage_threshold_value_check所设置的阈值（默认85%），越接近当前所设置的阈值越容易触发只读，影响业务运行。
  通过修改实例参数修改只读阈值，或者通过登录实例节点执行如下命令，调整只读阈值做紧急处理。调整后执行3。
  
  gs_guc reload -Z cmserver -N all -I all -c "datastorage_threshold_value_check = 90"
- 如果指标没有接近只读阈值，执行3。
排查xlog参数配置是否合理。

登录系统库，执行如下命令查看参数的配置

show wal_keep_segments;

如果指标值小于wal_keep_segments配置的值，xlog数量不会回收，会持续上涨，直到wal_keep_segments的值。
- 如果占用磁盘空间大了，可以调小。
  根据业务的实际情况，联系技术支持协助评估，调整wal_keep_segmengts的值。
wal_keep_segments：设置“pg_xlog”目录下保留事务日志文件的最小数目。
- 如果此参数配置过大，会占用更多的磁盘；
- 如果此参数设置过小，则在备机请求事务日志时，此事务日志可能已经被产生的新事务日志覆盖，导致请求失败，主备关系断开。
通过查看实例和节点信息，查看工作流存在正在执行的备份任务、DN扩容任务。
- 存在，待运维操作结束之后，此指标会回落，如果磁盘已经接近只读，或已经只读，优先考虑终止操作，联系技术支持协助评估。
- 不存在，执行5。
确认是否存在逻辑复制槽占用。
1. 登录系统库执行如下SQL：
```
select * from pg_get_replication_slots();
```
  以上示例中的红框为逻辑复制槽，slot_type列的值为logical，slot_name为slot_lsn。
2. 通过复制槽lsn，计算对应的xlog文件名，执行如下SQL：
```
select pg_xlogfile_name('restart_lsn');
```
  获取到查询结果如，供下方判断使用。
  
  restart_lsn需要换成上一步查出来的逻辑复制槽对应的restart_lsn，如上图所示。
  - 如果有逻辑复制槽，继续查看告警组件的pg_log日志中的关键字attempting to remove WAL segments older than log file，执行如下命令：
    grep 'attempting to remove WAL segments older than log file' postgresql-*.log
    
    获取到xlog编号，如。
  - 如果日志中确认对应的LSN长时间没有变化，且接近，则说明为逻辑复制槽占用导致，需要执行如下命令，清理逻辑复制槽解决，但是要注意，清理之前，需要和客户确认该复制槽是否仍需要使用，确认不使用之后再执行删除。
```
SELECT pg_drop_replication_slot('slot_name');
```
    slot_name为需要清理的复制槽的名字。
3. 清理结束之后，重新grep日志，发现lsn推进，xlog数量下降。
如果没有逻辑复制槽，执行6。
执行如下SQL查看视图，确认是否为备份失败导致。
```
SELECT * FROM pg_stat_get_wal_senders();
```
确认gs_roach占用的槽位的LSN是否为pg_log日志中attempting to remove WAL segments newer than log file对应的xlog编号。
- 如果是，则说明是备份失败导致，待下次备份正常触发则可以正常回收，无需处理。
  - 如果磁盘已经接近只读，但是备份任务需要很久才会触发，执行如下命令恢复：
    差备失败恢复：SELECT pg_drop_replication_slot('gs_roach_inc');
    
    全备失败恢复：SELECT pg_drop_replication_slot('gs_roach_full');
- 如果不是因为备份失败导致，执行7。
查看告警组件数据目录下是否存在delay_xlog_recycle文件。
- 存在，则不会回收xlog，执行如下命令恢复：
```
select * from pg_disable_delay_xlog_recycle();
```
- 不存在delay_xlog_recycle文件，执行8。
排查业务是否有大量的写入操作执行，导致xlog生成速率过快，来不及回收，导致xlog堆积，可以参考ALM-5101338 Ops巡检-xlog速率异常指标的处理方法。
如果上述场景均不涉及或操作之后指标仍未下降，联系技术支持处理。