半导体等核心MES制造执行系统是设备数据采集、设备联网管理、质量管理等数字化的制造核心应用软件。这不也就刚刚 ，国产数据库openGauss突发数据磁盘爆满，主备集群宕机，以下是故障紧急处理的全流程，分享给大家！

1.故障现象

由于半导体某制造业产能提升，原有部署的openGauss数据分区空间不足，直接造成openGauss集群宕机，造成核心应用故障，影响生产。

手动启动集群的时候已经发现无法启动，此时排查服务器分区使用情况，发现数据文件所在的磁盘分区/根目录使用已经到达100%

此时发现备库也无法使用，处于修复状态

2.故障处理

此时唯有停机进行数据文件分区的迁移，以下为处理的过程

2.1 挂载新的分区

通过LVM管的方式，在主备库挂在了/u01分区用于openGauss数据盘，后面进行迁移。

LVM 的全名是 Logical Volume Manager，
中文可以翻译作逻辑卷轴管理员。之所以称为“卷
轴”可能是因为可以将 
filesystem 像卷轴一样伸长或缩短之故吧！
LVM 的作法是将几个实体的
partitions或disk
通过软件组合成为一块看起来是独立的大磁盘VG，
然后将这块大
磁盘再经过分区成为可使用分区LV， 
最终就能够挂载使用了

2.2 停集群迁移

--此步操作为停集群
[omm@gaussdb1 ~]$  gs_om -t stop
Stopping cluster.
=========================================
Successfully stopped cluster.
=========================================
End stop cluster.

--此部操作为迁移openGauss数据路径
新建/u01分区的数据使用目录,记得授权哈
mkdir -p /u01/openGauss/data/dn
chmod 775 /u01 -R
chown omm:dbgrp /u01 -R
--记住omm用户下带权限拷贝
cp /openGauss/data/dn 
/u01/openGauss/data/dn -r

2.3 修改配置文件

openGauss安装前的配置文件非常重要，一定在安装后记得保存，防止后期集群变更使用。

以下只要修改安装部署使用的XML文件配置
红色部分，替换原有的路径/openGauss/data/dn
为现在的/u01/openGauss/data/dn即可

2.4 重构cluster_config配置

因为这套集群是CM管理的方式，需要找到cluster_config配置文件，搬移数据库后修改配置路径再启动。

在主库通过以下命令重构集群配置，并分发给备库
gs_om -t generateconf 
-X XMLFILE --distribute
注：XMLFILE就是安装集群的配置文件

以上命令执行后实际文件是修改的
$GAUSSHOME/bin/cluster_static_config
它是一个二进制文件，通过strings可以查看
我们发现主备库的集群配置都更新了
数据文件统一更新为了
/u01/openGauss/data/dn

2.5 重新启动集群

[omm@gaussdb1 ~]$ gs_om -t start
Starting cluster.
======================================================================
Successfully started primary instance. Wait for standby instance.

3.恢复后续工作

3.1 业务连接中断处理

数据库恢复后发现有一些报表业务，
短链接出现页面无法展示数据的问题，后台报以下错误
### Error querying database.  
Cause: org.postgresql.util.PSQLException: 
FATAL: terminating connection due to administrator command

原因如下；
长连接但是长期不用，然后第一次做sql 
就报错会话超时了
确定长连接用的中间件，
有定期空闲后去select做一下
下保活的机制即可。
本次是将
session_timeout 改为 0 关掉后
故障恢复了

3.2 统计信息处理

业务恢复后发现部分查询界面无法出结果，因为是做了数据盘的迁移，需要做一次全库的统计信息即可

openGauss统计信息会自动收集，10min一次，
死元祖超过10%的阈值才会满足触发条件收集统计信息，
生产环境可以改小点。
--重点关注的参数如下：
autovacuum_mode
autovacuum_naptime
autovacuum_analyze_scale_factor

处理的办法就是给全库做了一下统计信息的收集

核心的大表数据也根实际吻合了

4.总结

通过这一次故障我们发现，其实在国产库数据库的使用过程中，必不可少的会有一些故障，这是正常的。我们需要的是完善的处理机制，需要的是大量的案例供我们的用户参考使用，希望这次故障的处理能帮助到大家！