openGauss常见问题与故障处理（二）

2.网络故障定位手段
2.1 网络故障定位手段--常见网络故障引发的异常
在数据库正常工作的情况下，网络层对上层用户是透明的，但数据库在长期运行时，可能会由于各种原因导致出现网络异常或错误。
常见的因网络故障引发的异常有：
1> 数据库启动失败，报网络错误
2> 状态异常，如：节点上所有的实例都是unknown或者所有主机都切换为备机
3> 网络连接建立失败
4> 对数据库执行SQL操作时，报网络异常中断的错误
5> 连接数据库或执行查询时发生进程停止响应。数据库出现了网络故障后，主要通过使用Linux系统提供的网络相关命令工具
（ping、ifconfig、netstat、lsof等），进程堆栈查看工具（gdb、gstack）,结合数据库的日志信息，进行分析定位。
本节通过举例介绍常见的网络问题，并进行基本的分析定位。

2.2 网络故障定位手段--数据库启动失败，报网络错误
问题现象1：
日志中存在如下错误信息，可能是端口被其他进程侦听
LOG:cloud not bind socket at the 10 time,is another postmaster already running on port 26000?

处理方法：
执行如下命令查看侦听该端口的进程，端口号请根据实际端口号替换
Gaiem# netstat -anop | grep 14880
根据查询结果，强行停止正在占用端口的进程或者更改数据库侦听端口

问题现象2：
使用gs_om -t status --detail查询状态，如果显示主备间连接未建立。

处理方法：
在openEuler操作系统下，使用systemctl status firewalld.service命令，查看节点上是否开启了防火墙。
如果开启，使用systemctl stop firewalld.service关闭防火墙
# systemctl status firewalld.service
操作系统不同，命令可能不同，使用对应操作系统命令查看修改

2.3 网络故障定位手段--数据库状态异常
问题现象：
某一节点上出现所有实例都是unknown或者所有主实例都切换成了备实例或者查询中出现大量connection reset by peer,connection timed out等报错信息。

所有实例都是unknown这种状态，大家可能平时很少遇到过，所以对这种状态的理解，咱们可以举一个模拟场景中的肖荏盖的反向的例子来帮助大家理解。

对于初学者入门的学习，一些理论不容易理解或记住，所以本节课程【创新】采用了【正、反对比联想记忆】的方法，
引入模拟场景中的肖荏盖的小故事。（模拟场景为虚构演绎，仅供教学，不要对号入座，懂不懂？明白吗？）

【数据库的功能都是正向的，模拟场景中的肖荏盖做的事情都是反向的。】

模拟场景：肖荏盖接到一个电话，让他们去某个公司帮忙解决问题，其实这个问题就是比较高级的问题了，鱿鱼肖荏盖一直是中级工程师，而且喜欢自吹自擂，名不副实，所以到了现场解决不了那个问题。
他就打电话问遍了芸芬愁砚所有的工程师，结果是全都回答：不会。
肖荏盖只能偷偷摸摸求助某上市公司超级大师蓝阔福的徒弟，康副业来解决问题。
在模拟场景中，肖荏盖的行业里有这么一个传言，就是芸芬愁砚的每一个人都是酒囊饭袋，其实这种说法是错误的、是不负责任的、是不准确的。
准确的说法是：芸芬愁砚只有肖荏盖一个人是纯酒囊，芸芬愁砚的其他人每一个人酒量都不是很好，都是纯饭袋，只有他们组合起来，形成合力，才是真正的酒囊饭袋。
所以，平时学知识的时候，也不能因为人云就亦云，要有自己的分析和见解，模拟场景中，超级大师蓝阔福正是坚定自己的信念，坚守正道，不断学习，才取得真正的成功，带领他的公司成为上市公司。
反观肖荏盖，天天就像丘处机一样，到处说自己从业多少多少年，每次开饭之前先说一遍，从业多少年（大家不要误会，这可不是什么祷告词），肖荏盖喝完了酒还是这一套，从业了多少年，实际技术功力完全就是没有任何提升，
肖荏盖从业几十年，唯一提升最明显的，那就是酒量了。
肖荏盖经常在喝醉了就各种承诺技术兜底，其实他们全体中级工程师根本不具备兜底的能力，全指望某上市公司超级大师蓝阔福的徒弟，康副业。
由此可见，超级大师蓝阔福的徒弟们，还都是很厉害的，毕竟随便请出来一位徒弟，接一接私活，都能挽救一个濒临倒闭的公司呢。当然，也不是白挽救，肖荏盖也不是白求人家徒弟的，这也很正常的。
所以，提醒大家，打铁还需自身硬，要向模拟场景中的超级大师蓝阔福学习，不要向模拟场景中的肖荏盖全家学习。

读完模拟场景，我们还是要回到现实，重新来看问题现象：
某一节点上出现所有实例都是unknown或者所有主实例都切换成了备实例或者查询中出现大量connection reset by peer,connection timed out等报错信息。

处理办法：
1> 如果ssh不能连接故障机器，在其他机器上使用ping命令向该机器发数据包。如果可以ping通，说明可能是该资源（内存、CPU、磁盘）耗尽导致不能建立连接。
2> 如果ssh可以连接该机器，尝试执行查询，并每隔1s执行/sbin/ifconfig eth?（?代表数字，表示第几个网卡）命令，
查看如下信息中的dropped及errors值的变化情况，如果增长迅速，可能是网卡或网卡驱动故障。
ifconfig enp42zdrsggq

2.4 网络故障定位手段--网络连接建立失败
问题现象1：节点连接其他节点失败，日志中报出“connection refused”错误
处理办法：
1> 查看端口是否配置错误，导致连接时使用的端口并非对方侦听的端口。查看报错节点配置文件postgresql.conf记录端口号与对方侦听的端口号是否一致。
2> 查看对方端口侦听是否正常（可以使用“netstat -anp”命令）或者查看对方进程是否存在。

问题现象2：对数据库执行SQL操作时，获取连接描述符失败，报错如下：
WARNING:29483313:incomplete message from client:4905,9
WARNING:29483313:failed to receive connDefs at the time:1.
ERROR:29483313:failed to get pooled connections

在日志中，找到上面的错误，并向上查看一段日志内容，可以看到详细的错误信息，常见的错误如下所示，
主要是由于主备信息不正确导致。
FATAL:dn_6001_6002：can not accept connection in pending mode.
FATAL:dn_6001_6002：the database system is starting up.
FATAL:dn_6009_6010：can not accept connection in stanby mode.

处理办法
使用gs_om -t status --detail查询状态，确认是否发生过主备切换，重置实例状态。
此外，需要查看连接失败的节点是否发生了core或者重启。通过om日志可以查看到是否发生了重启。

2.5 网络故障定位手段--执行SQL报网络异常中断错误
问题现象1：查询执行失败，报错信息如下。
ERROR:dn_6065_6066:Failed to read response from Datanodes.Detail:Connection reset by peer.Local:dn_6065_6066
Remote:dn_6023_6024
ERROR:Failed to read response from Datanodes Detail:Remote close socket unexpectedly
ERROR:dn_6155_6156:dn_6151_6152:Failed to read vector response from Datanodes

连接建立失败，报错信息如下：
ERROR:Distribute Query unable to connect xxx.xxx.xxx.xxx:14600 [Detail:stream connect connect() fail:Connection timed out]
ERROR:Distribute Query unable to connect xxx.xxx.xxx.xxx:12600 [Detail:receive accept response fail:Connection timed out]

处理办法：
使用gs_check检查网络配置是否符合标准
查看是否有进程发生core或重启，以及主备切换
如果不存在上述问题，可以联系网络技术人员做具体分析。