Mogdb - 处理由于参数版本更迭导致备份失败及空间爆满问题一则

今天处理了一个MogDB数据库问题，具有很强的代表性。当做经典案例整理总结一下。

背景

数据库版本是MogDB 2.0.1，之前根据用户需求使用ptk工具将单实例数据库扩容为双节点集群(一主一备)，这是故障发生的前提。

故障现象

用户发现备份报警，同时数据库数据文件空间暴涨至88%。

处理流程

1、可以看到备份在10月31日就已经失败，检查数据库备份日志$GAUSSLOG/brm/brm.log后发现，出现管道连接超时(socket timeout)，导致pg_stop_backup()函数失败

cat brm.log.20241104|grep -i error

2、在OG社区简单搜索了一下，发现一个类似的issue

3、根据文档描述内容，检查参数和复制槽，发现复制槽失效

gsql -r
show most_available_sync;
synchronous_standby_names;
select * from pg_stat_replication;

4、赶紧检查备节点状态，发现mogdb数据库进程已经down了

ptk cluster -n mogdb status --detail

5、登录备节点，检查日志，发现大量的报错WARNING: remote service port not available,导致目录空间使用率达到了100%，mogdb备库down掉。

6、初步怀疑该问题是有网络通信导致的，检查pg_hba.conf未发现错误点

7、继续检查replconninfo参数，检查同步参数时，发现一个小端倪，该参数在OG 2.0版本需要配置3个端口，3.0配置时，可以忽略service端口(port+4)，该参数明显没有service配置，推测可能是由于这个原因导致了频繁报错的出现

show replconninfo1;

8、修改并重载参数后，问题消失

alter system set replconninfo1='localhost=xxx.xxx.xxx.xxx localport=51001 localservice=51004 localheartbeatport=51005 remotehost=yyy.yyy.yyy.yyy remoteport=51001 remoteservice=51004 remoteheartbeatport=51005'
select pg_reload_conf();

9、目录空间回落

df -h

总结

该问题本质是由于版本更迭导致的，一个参数设置的不同，导致了连锁反应，向多米诺骨牌一样，问题越来越严重，如果不及时处理，最终会滑向深渊。