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方案如下：

https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=75275

该场景下实例处于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

若实例长时间处于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后发现不属于该场景请联系华为工程师进行处理。

编号

日志内容

处理方案

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

根据步骤一查到异常实例信息，使用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实例为何长时间无法升主，具体排查与修复方案参考以下链接：

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状态。

使用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状态，该状态持续时间较长（超过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进程运行时间与其他实例不同

查看集群状态不均衡需要分析主备切换原因。

若存在以上情况可按照以下步骤进行分析

使用root用户查看/var/log/messages日志在实例重启时间点是否有kill关键字，若存在则说明由于max_process_memory参数设置过大，将参数修改为适当值进行观察，该参数计算方式详细见产品文档。

使用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文件产生路径查看参考以下命令：

cat /proc/sys/kernel/core_pattern，该命令结果为绝对路径直接在对应目录查看，否则在对应重启实例查看。

若产生core文件解析core文件将堆栈反馈给华为工程师进行处理。

若集群集群配置core集群实例多次重启并且不属于步骤一与步骤二的场景，请联系华为工程师处理。

EI企业智能 Gauss AP 数据仓库服务 GaussDB(DWS)

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。