【GaussDB】如何避免Ops巡检-xlog数量异常？告警解释此告警对应指标“xlog数量”超出配置阈值，此指标反映

告警解释

=======

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

对系统的影响

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

可能原因

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速率异常指标的处理方法。
如果上述场景均不涉及或操作之后指标仍未下降，联系技术支持处理。