作者:IT邦德
中国DBA联盟(ACDU)成员,10余年DBA工作经验,
Oracle、PostgreSQL ACE
博客专家及B站知名UP主,全网粉丝10万+
擅长主流Oracle、MySQL、PG、
高斯及Greenplum备份恢复,
安装迁移,性能优化、故障应急处理
公众号:IT邦德
半导体等核心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.总结
通过这一次故障我们发现,其实在国产库数据库的使用过程中,必不可少的会有一些故障,这是正常的。我们需要的是完善的处理机制,需要的是大量的案例供我们的用户参考使用,希望这次故障的处理能帮助到大家!