【实例状态】GaussDB DN服务异常（上）

AI小学徒夏夏秀才 2022-11-26 17:33:48

通过OPS确认节点状态是否已经恢复，或登录后台，执行cm_ctl query -Cv确认集群是否已经Normal。

如果状态已经为normal，表明故障已经恢复，集群正常，不再影响业务。确认是否需要分析故障的具体原因，如果需要，继续向下跟随文档进行分析。

确定是否为底层故障

首先确认是否是物理机、虚拟机、网络，底层故障等环境因素导致。

出现如下现象，大概率是底层故障：

现象一：同时出现大量告警。不区分节点分类。

现象二：闪报，告警之后，马上恢复。

总之，不管是何现象，先确认底层是否故障。

深入分析

本文档各步骤都会用到集群信息，执行cm_ctl query -Cvipd 命令查询集群状态，各信息含义如下图：

查询集群状态，DN状态为Normal

问题现象：

DN服务异常。

问题分析及定界：

DN状态显示Normal，说明DN故障已经恢复，需要查看日志分析DN故障原因。分析步骤：

Case1：登录故障dn节点，查看cm_agent日志：

cd $GAUSSLOG/cm/cm_agen # 找到告警时间点的日志文件cm_agent-xxx.log
复制

Case2：在cm_agent日志中搜索如下关键字(这些关键字在日志中处于同一行)，如果有，按照描述处理，如果没有，跳转到步骤c

datanodeId=6001, dn_manual_stop=0, dn_disk_damage=0, nic_down=0, port_conflict=0, dn_build=0, dn_start_counts=0. 
# 最新版本也可能是如下所示：
datanodeId=6030, dn_manual_stop=0, g_dnDiskDamage=0, g_nicDown=0, port_conflict=1, g_dnBuild=0, g_dnStartCounts=0.
复制

各个标记含义：

dn_manual_stop=1，表示DN进程被停止过，通常有两种原因：（1）被用户停止（2）节点网络断开，被集群管理停止，执行处理步骤1。

dn_disk_damage=1 或 g_dnDiskDamage=1，表示磁盘故障，查看DN数据目录是否存在，目录权限是否正常，磁盘是否故障，磁盘是否满。执行处理步骤2。

nic_down=1或 g_nicDown=1 或 can’t find nic related with xxx，表示网卡故障, root 用户执行ifconfig命令查看网卡是否down掉，ethx口上的IP是否存在，执行处理步骤3。

port_conflict=1，表示端口冲突，查看同目录下对应时间点的system_call-xxx.log日志，该日志中记录了当时端口被那个进程占用了,如下。

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
gaussdb 24726 Ruby 9u IPv4 4143766500 0t0 TCP pekphisprc09662:42100 (LISTEN)
复制

或使用lsof -i:port确认。

绝大部分情况下，端口占用是由于DN进程重启，老进程退出没有及时释放端口，这种情况等待几秒到数十秒后，端口释放后新的DN进程就可以启动。执行处理步骤4。

Case3：在cm_agent日志中搜索如下关键字：restart msg from cm_server。如果没有，跳转到步骤Step4。

如果有，说明DN进程被CM重启过，可能原因及处理方式如下：

oCMserver仲裁DN主备时重启。

o进程僵死重启。登陆cmserver主节点，查看日志，检查当时网络读写、CPU、内存、磁盘等监控指标，是否有升高压力。

cd $GAUSSLOG/cm/cm_server # 查看对应时间的cm_server-xxx.log日志, 搜索如下信息
phony dead times(5:5) already exceeded, will restart(6001) 或者 restart %u, there is not report msg for %d sec. 
复制

Case4：cm_agent日志中没有Step2、Step3中的关键字，但是有“DN START”关键字，DN进程可能是core掉重启，按照《查询集群状态，告警DN状态为CoreDump》章节处理，如果没有“DN START”关键字，转到Case5。

Case5：如果DN进程没有重启过：查看DN日志 cd $GAUSSLOG/pg_log/dn_60xx, 找到告警时间点的日志，查看是否有报错，确认、收集保存错误日志。登陆cmserver主所在节点, cd $GAUSSLOG/cm/cm_server，根据告警时间点，查看cm_server-xxx.log, 查看是否有报错信息，收集保存错误日志。如果CMserver日志有如下【fenced UDF(34) heartbeat timeout, heartbeat:7, threshold:6. 】表示当时DN节点上的cm_agent与cm_server主节点之间短暂超时，查看当时网络读写、CPU、内存、磁盘等监控指标，是否有升高压力。

Case6：登陆cmserver主所在节点，cd $GAUSSLOG/cm/cm_server，根据告警时间点，查看cm_server-xxx.log，搜索关键字Set database to read only mode此日志表示当时磁盘使用率超过阈值，DN被设置为只读状态。同时到cm_server数据目录/var/chroot/usr/local/cm/cm_server查看cm_server.conf 配置文件，查看参数datastorage_threshold_value_check的值，当磁盘使用率超过该参数值时，DN就会被设置为只读，避免磁盘被写满。df -h查看磁盘使用率，查看DN数据目录所在磁盘使用率。