GaussDB(DWS)集群状态异常问题处理套路
GaussDB(DWS)集群故障问题处理套路
【使用前提】
加载环境变量（仅线下纯软形态需要）：source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile
build相关日志路径：$GAUSSLOG/bin/gs_ctl
cm_agent日志路径：$GAUSSLOG/cm
实例日志路径：$GAUSSLOG/pg_log/dn_xx
系统日志（仅root用户）：/var/log/message
【试用场景】
本方案适用以下场景：实例故障导致集群降级或不可用、实例状态长时间处于catchup状态、单实例目录下pg_xlog文件积压。碰到以上场景按照对应方案处理，根据实例状态找到对应案例或处理步骤进行处理。如下表：
| 维度 |
使用场景 |
确认方式 |
| 明确问题场景 |
集群降级 |
cm_ctl query |
| 集群不可用 |
cm_ctl query |
|
| 实例目录pg_xlog较大 |
|
|
| 实例长期处于catchup |
cm_ctl query -Cvd |
|
| 实例重启或主备切换 |
cm_ctl quer -Cvds |
1 集群降级状态，业务可以正常连接
集群状态为degraded状态，该场景下业务可以正常连接，按照故障实例状态找到对应处理案例进行恢复。故障实例状态与处理见下表：
| Check项 |
异常值 |
处理方式 |
Check方法 |
| 实例状态 |
Need repair |
1.1章节 |
cm_ctl query –Cv |
| Pending starting |
1.2章节 |
||
| Disk damaged |
1.3章节 |
||
| Down unknown |
1.4章节 |
||
| Build failed |
1.5章节 |
||
| Manually stopped |
1.6章节 |
1.1 Need repair
若碰到实例状态为need repair状态按照以下步骤进行排查。
步骤一：查看实例状态
| cm_ctl query –Cvd|grep -i "Need repair" |
查询异常实例状态如下：
| 1 10-185-179-67 6001 /srv/BigData/mppdb/data1/master1 P Primary Normal | 2 10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Standby Need repair(Normal) | 3 ASG003 3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal |
步骤二：判断实例是否redo
若为redo状态则为正常状态，等待自己恢复即可；若未进行redo则按照后续步骤继续进行排查。判断实例redo方案如下：
https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=75275
步骤三：查看pg_log日志
该场景下实例处于standby need repair状态，查看异常实例最新pg_log日志（该日志在$GAUSSLOG/pg_log/dn_xx路径下）是否有如下关键日志：
| 编号 |
日志内容 |
处理方案 |
| 1 |
PANIC |
联系华为工程师 |
| 2 |
could not connect to the primary server: GSSAPI |
步骤四 |
排查pg_log按照对应处理方案处理。
步骤四：修复实例
方案一：从前台关闭kerbos，注意该方式会自动重启集群生效，业务会中断。
方案二：在后台关闭kerbos，该方案不需要重启集群，但是可能会存在前台kerbos状态与后台不一致情况，对业务无影响。后台关闭kerbos命令如下：
| gs_ssh -c "gs_om -t kerberos -m uninstall -U omm" |
1.2 Pending starting
该状态下与1.1排查思路相同，部分场景可能会有差别，排查步骤如下：
步骤一：查看实例状态
| cm_ctl query –Cvd|grep -i "Pending Starting" |
其中6001为故障dn实例编号，具体排查时替换为对应故障实例编号，状态如下：
| 1 10-185-179-67 6001 /srv/BigData/mppdb/data1/master1 P Primary Normal | 2 10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Pending Starting | 3 ASG003 3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal |
步骤二：判断实例是否redo
若实例长时间处于pending starting，则该实例大概率进行redo为正常状态，等待自己恢复即可；若未进行redo则按照后续步骤继续进行排查。判断实例redo方案如下：
https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=75275
步骤三：确认是否存在数据文件损坏
若实例状态在pending starting与其他状态来回切换则说明可能该实例有文件损坏。
查看异常实例最新pg_log日志（该日志在$GAUSSLOG/pg_log/dn_xx路径下）是否有如下关键日志：
其中6001为故障dn实例编号，具体排查时替换为对应故障实例编号，状态如下：
| 编号 |
日志内容 |
| 1 |
The parameter destMax is equal to zero or larger than macro |
| 2 |
PANIC |
若日志中以上任意一个日志则符合该场景，实例状态不会自行恢复需要人为干预，联系华为工程师进行修复。若排查pg_log后发现不属于该场景请联系华为工程师进行处理。
步骤四：排查systemcall日志
| 编号 |
日志内容 |
处理方案 |
| 1 |
Input/output error |
|
| 2 |
Cannot allocate memory |
http://rnd-dayu.huawei.com:8081/index.php/Question/detail?id=56912 |
| 3 |
Could not create semaphores |
http://rnd-dayu.huawei.com:8081/index.php/Question/detail?id=37396 |
按照以上应急方案进行处理
1.3 Disk damaged
实例为该状态下不会自行恢复，按照以下步骤进行逐一排查
步骤一：查看异常实例信息
| cm_ctl query –Cvd|grep 6001 |
其中6001为故障dn实例编号，具体排查时替换为对应故障实例编号，状态如下：
| 1 10-185-179-67 6001 /srv/BigData/mppdb/data1/master1 P Primary Normal | 2 10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1 S disk damaged | 3 ASG003 3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal |
根据集群状态可以看到异常实例以下信息
异常实例所在节点为：10-185-179-95
异常实例路径为：/srv/BigData/mppdb/data1/slave1
步骤二：查看实例所在磁盘使用率是否达到100%
根据步骤一查到异常实例信息，使用omm用户登录至异常实例所在节点（10-185-179-95）查看磁盘使用情况
| df -lh |
| 10-185-179-67:~ # df -lh Filesystem Size Used Avail Use% Mounted on /dev/sda2 823G 122G 701G 15% / udev 95G 248K 95G 1% /dev tmpfs 95G 1.8M 95G 1% /dev/shm /dev/sdd1 2.5T 650G 1.9T 26% /srv/BigData/mppdb/data2 /dev/sdc1 2.5T 34M 2.5T 1% /srv/BigData/mppdb/data3 /dev/sde1 2.5T 2.5T 0 100% /srv/BigData/mppdb/data1 /dev/sdb1 2.5T 34M 2.5T 1% /srv/BigData/mppdb/data4 |
根据排查结果发现异常实例所在磁盘使用率已经达到100%，此时联系华为工程师处理！！若磁盘使用率远远未达到100%继续进行排查。
步骤三：实例所在磁盘损坏
【排查&&处理方案】
- 查看主机BMC监控页面是否有告警，若BMC监控页面存在磁盘告警则说明磁盘故障。
- 手动在实例目录所在磁盘创建文件是否能够成功，若能成功创建则磁盘正常。否则说明磁盘故障
若存在磁盘故障请联系硬件工程师对磁盘进行排查。硬件故障修复后对该实例按照gs_repalce方案进行修复，参考标准方案：
https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=145788
步骤四：实例所在磁盘分区挂载异常
| df -lh |
| 10-185-179-67:~ # df -lh Filesystem Size Used Avail Use% Mounted on /dev/sda2 823G 122G 701G 15% / udev 95G 248K 95G 1% /dev tmpfs 95G 1.8M 95G 1% /dev/shm /dev/sdd1 2.5T 650G 1.9T 26% /srv/BigData/mppdb/data2 /dev/sdc1 2.5T 34M 2.5T 1% /srv/BigData/mppdb/data3 /dev/sdb1 2.5T 34M 2.5T 1% /srv/BigData/mppdb/data4 |
如上结果磁盘挂载少了data1，若属于该情况使用以下命令进行挂载：
| mount -a |
挂载成功后对该盘所在实例使用gs_replace进行修复。若未成功挂载请联系操作系统工程师进行排查。
gs_replace修复方案：
https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=145788
步骤五：实例目录丢失
根据步骤一查到异常实例路径为：/srv/BigData/mppdb/data1/slave1
| ll /srv/BigData/mppdb/data1/slave1 |
若该目录为空或者不存在则按照实例修复方案进行修复。具体修复方式见标准方案：
https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=145788
1.4 Down unknown
该状态下实例无法自行恢复，请参考以下场景进行恢复
步骤一：查看异常实例信息
| cm_ctl query –Cvd|grep 6001 |
其中6001为故障dn实例编号，具体排查时替换为对应故障实例编号，状态如下：
| 1 10-185-179-67 6001 /srv/BigData/mppdb/data1/master1 P Primary Normal | 2 10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Down Unknown | 3 ASG003 3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal |
根据集群状态可以看到异常实例以下信息
异常实例所在节点为：10-185-179-95
异常实例路径为：/srv/BigData/mppdb/data1/slave1
步骤二：确认该实例是否存在文件损坏
查看该实例最新日志（$GAUSSLOG/pg_log/dn_xxx）是否存在以下关键字：
| 编号 |
日志内容 |
| 1 |
Input/output error |
若存在该报错由于磁盘坏道等硬件故障导致，确认磁盘无异常后请联系华为工程师进行处理。
步骤三：确认system_call日志
查看该实例所在节点最新system_call日志（$GAUSSLOG/pg_log/cm_agent/system_call-xxx-curent.log）是否存在以下关键字：
| 编号 |
日志内容 |
| 1 |
invalid value for parameter |
若出现该关键字说明配置文件被异常修改，查看对应备机实例或者其他实例该参数如何配置，正确修改该实例目下postgresql.conf即可自行恢复。
若按照以上步骤排查完均不符合请联系华为工程师处理。
1.5 Build failed
【原因分析】
实例未该状态不会自行恢复，可以不需要做排查按照修复方案进行修复，若需要分析该状态原因可以查看gs_ctl（$GAUSSLOG/bin/gs_ctl）日志报错提示，一般有以下几个原因：
1）xlog被回收
2）build过程中与主机网络闪断
【问题修复】
通过gs_replace方案进行修复：
https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=145788
若使用该方案仍然无法恢复请联系华为工程师处理。
1.6 Manually stopped
该状态为现场手动停止，需要跟现场了解手动停止原因，若无数据损坏等故障场景则可手动拉起该实例。手动启实例命令如下：
cm_ctl start -n $nodeid -D xxxx
2 集群不可用，业务中断
集群状态为unavailable状态，该类型集群故障我们目标在于先将其恢复至降级状态，恢复业务后再根据第一章继续进行恢复。集群不可用实例故障组合状态较多，常见类型如下表：
| Check项 |
异常值 |
说明 |
Check方法 |
|
| 实例状态 |
主 |
备 |
|
cm_ctl query –Cv |
| Down unkown/ Disk damaged/ Pending starting/ need repair/ build failed |
promoting |
故障场景下备机升主时长时间未成功 |
||
| promoting |
demoting |
手动进行集群均衡时长时间不成功 |
||
| down unkown/ disk damaged |
need repair |
实例故障时主实例未触发升主流程 |
||
| Need repair/ pending starting |
need repair |
实例故障时主实例未触发升主流程 |
||
| 从备down unkown 集群不可用 |
om_monitor进程异常 |
|||
2.1备：promoting主：down unkown/disk damaged/pending starting/need repair/build failed
步骤一：查看实例状态
| cm_ctl query –Cvd|grep 6001 |
其中6001为故障dn实例编号，具体排查时替换为对应故障实例编号，状态如下：
| 1 10-185-179-67 6001 /srv/BigData/mppdb/data1/master1 P Pending Need repair | 2 10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Standby Promoting | 3 ASG003 3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal |
根据集群状态可以看到异常实例以下信息：
6002处于promoting
6001处于pending need repair
该场景属于此章节实例状态组合场景，该状态持续时间较长（超过30min）说明为异常情况，按照步骤二进行排查。
步骤二：查看长时间promoting原因
实例状态为以上组合时，说明主实例故障备机触发升主流程若该状态保持较长时间（超过半小时）则为异常情况，只需要关注promoting实例为何长时间无法升主，具体排查与修复方案参考以下链接：
https://bbs.huaweicloud.com/blogs/239867
2.2 主：promoting；备：demoting
步骤一：查看实例状态
| cm_ctl query -Cvd|grep 6001 |
其中6001为故障dn实例编号，具体排查时替换为对应故障实例编号，状态如下：
| 1 10-x-179-67 6001 /srv/BigData/mppdb/data1/master1 P Standby Wait promoting | 2 10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Primary Demoting | 3 ASG003 3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal |
根据集群状态可以看到异常实例以下信息：
6002处于Standby Wait promoting
6001处于Primary Demoting
该场景属于此章节实例状态组合场景，该场景出现在手动执行均衡集群时出现，持续时间较长（超过30min）说明为异常情况，按照步骤二进行排查。
步骤二：查看实例状态
主机为promoting备机为demoting，该场景为现场手动均衡集群时长时间未成功（超过半小时），则按照均衡集群失败帖子排查：
https://bbs.huaweicloud.com/blogs/203410
2.3 主：need repair/pending starting；备：need repair
步骤一：查看实例状态
| cm_ctl query –Cvd|grep 6001 |
其中6001为故障dn实例编号，具体排查时替换为对应故障实例编号，状态如下：
| 1 10-x-179-67 6001 /srv/BigData/mppdb/data1/master1 P Pending Starting | 2 10-x-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Standby Need repair(Normal) | 3 ASG003 3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal |
根据集群状态可以看到异常实例以下信息：
6001处于Pending Starting
6002处于Standby Need repair(Normal)
该场景属于此章节实例状态组合场景，持续时间较长（超过10min）说明为异常情况，按照步骤二进行处理。
步骤二：触发升主流程
该场景下由于主实例异常退出被重新拉起后没能redo完恢复至故障前状态，cm_server未触发仲裁机制，导致集群不可用。
手动停止6001实例，待备机6002触发升主流程进行恢复，若停止后有实例长时间处于promoting（超过半小时）则按照2.1章节进行排查。
| cm_ctl stop -n 1 -D /srv/BigData/mppdb/data1/master1 |
2.4 从备实例down unknown，集群不可用
步骤一：查看实例状态
| cm_ctl query –Cvd|grep Down |
其中6001为故障dn实例编号，具体排查时替换为对应故障实例编号，状态如下：
| 1 10-x-179-67 6001 /srv/BigData/mppdb/data1/master1 P Primary Normal | 2 10-x-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Standby Normal| 3 ASG003 3002 /srv/BigData/mppdb/data1/dummyslave1 R Down Unknown 2 10-x-179-95 6007 /srv/BigData/mppdb/data2/master2 P Primary Normal | 1 10-x-179-67 6008 /srv/BigData/mppdb/data1/slave2 S Standby Normal | 3 ASG003 3005 /srv/BigData/mppdb/data2/dummyslave2 R Down Unknown |
根据集群状态可以看到 ASG003所在节点两个从备实例3002与3005都为Down Unknown状态。
步骤二：确认om_monitor进程
使用omm用户登录ASG003节点查看是否有两个om_monitor进程
| ps -ef|grep om_monitor|grep -v grep |
若存在手动kill两个om_monitor进程，待自动拉起后集群状态恢复正常。
3 xlog积压
xlog积压场景一般体现在磁盘使用率较高，或者某一磁盘使用率明显高于其他磁盘。根据磁盘100%排查方案进行排查时发现，部分实例路径下pg_xlog目录过大（超过100G）可参考此修复方案。
步骤一：查看实例xlog文件大小信息
| du -sh /srv/BigData/mppdb/data1/master1/pg_xlog |
其中/srv/BigData/mppdb/data1/master1为实例路径，若该大小超过100G则按以下方案处理
步骤二：xlog积压排查
| 场景 |
说明 |
Check方法 |
| 延迟xlog文件回收 |
备份过程中产生该文件，该文件存在不会对xlog进行回收 |
查看积压实例下是否存在delay_xlog_recycle文件并且此时无备份任务。 |
| 复制槽异常 |
复制槽推进后才会回收xlog，复制槽推进异常时会影响xlog回收 |
连接对应dn查询： select * from pg_get_replication_slots(); 查看两条记录（主备与主从）restart_lsn字段是否相差较多。 |
| checkpoint失败（较少） |
xlog回收由checkpoint触发 |
pg_controldata $path $path为实例路径 查看Latest checkpoint location值是否较小 |
| wal_keep_segments |
控制保留xlog文件个数 |
连接dn查询： show wal_keep_segments; 查看改值是否过大（1024以下均正常） |
具体排查方案及处理见以下链接：
https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=83191
4 实例处于catchup状态
步骤一：查看实例状态
| cm_ctl query –Cvd|grep Catchup |
其中6001为故障dn实例编号，具体排查时替换为对应故障实例编号，状态如下：
| 1 10-x-179-67 6001 /srv/BigData/mppdb/data1/master1 P Primary Normal | 2 10-x-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Standby Catchup| 3 ASG003 3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal 2 10-x-179-95 6007 /srv/BigData/mppdb/data2/master2 P Primary Normal | 1 10-x-179-67 6008 /srv/BigData/mppdb/data1/slave2 S Standby Catchup | 3 ASG003 3005 /srv/BigData/mppdb/data2/dummyslave2 R Secondary Normal |
根据集群状态可以看到6002与6008处于catchup状态。
步骤二：确认catchup场景并处理
根据步骤一查看实例状态有实例处于catchup状态，该状态持续时间较长（超过12~24小时）或业务反馈慢均为异常情况，需要人工排查catchup原因，通常影响实例catchup因素见下表：
| 场景 |
说明 |
Check方法 |
| 带索引导入、delete单表 |
业务异常产生较多xlog |
解析主实例日志是否有较多delete或者Btree insert等关键字类型日志，解析命令如下： pg_xlogdump $xlogfile $xlogfile为任意xlog文件 |
| 锁冲突（数据页） |
业务语句与catchup线程抢锁 |
查看主实例最新pg_xlog日志是否存在以下关键字：ERROR: Lock wait timeout |
| bcm文件残留、bcm文件损坏 |
根据bcm文件未找到应数据文件，catchup线程反复被拉起 |
查看主实例最新pg_log日志是否有以下日志： could not open file |
具体排查与处理方案见以下链接：
https://bbs.huaweicloud.com/blogs/242269
5 实例重启或主备切换
集群运行过程当中发现有：
- FI监控页面有主备断连或者不同步告警:
| 编号 |
日志内容 |
| 1 |
Datanode主备不通过或者断连，重要，xxxx |
- ps -ef 查看某一节点上gaussdb进程运行时间与其他实例不同
- 查看集群状态不均衡需要分析主备切换原因。
若存在以上情况可按照以下步骤进行分析
步骤一：判断是否由于内存不足被oom
使用root用户查看/var/log/messages日志在实例重启时间点是否有kill关键字，若存在则说明由于max_process_memory参数设置过大，将参数修改为适当值进行观察，该参数计算方式详细见产品文档。
步骤二：是否被cma kill
使用omm用户（云上版本使用Ruby用户）查看cm_agent日志（$GAUSSLOG/cm/cm_agent/cm_agent-xxx.log）在实例重启时间点是否有kill关键字，若存在则说明dn hang或者cm_agent与cm_server连接异常，若该问题偶尔出现一次可不需做任何处理，若出现较为频繁联系华为工程师处理。
步骤三：进程core
首先确认该集群是否配置操作系统core，若为配置请先配置操作系统core之后继续观察。core配置方案见以下链接：
若该集群已经配置core请检查在对应目录检查是否有core文件产生，core文件产生路径查看参考以下命令：
cat /proc/sys/kernel/core_pattern，该命令结果为绝对路径直接在对应目录查看，否则在对应重启实例查看。
若产生core文件解析core文件将堆栈反馈给华为工程师进行处理。
若集群集群配置core集群实例多次重启并且不属于步骤一与步骤二的场景，请联系华为工程师处理。
- 点赞
- 收藏
- 关注作者
评论（0）