通信网络层是分布式数据库的基础组件，在数据库正常工作的情况下，网络层对上层用户是透明的，但分布式集群数据库在长期运行时，可能会由于各种原因导致出现网络异常或错误。

GaussDB 200常见的因网络故障引发的异常有：

分布式数据库出现了网络故障后，主要通过使用Linux系统提供的网络相关命令工具(ping、ifconfig、netstat、lsof等)，进程堆栈查看工具(gdb、gstack)，结合数据库的日志信息，进行分析定位。本节通过举例介绍常见的网络问题，并进行基本的分析定位。

集群启动失败，报网络错误

问题现象1：

日志（日志位置请参考日志章节）中有如下错误信息，可能是端口被其他进程监听：

LOG: could not bind socket at the 10 time, Is another postmaster already running on port 54000?

处理办法：

执行如下命令查看是什么进程监听了该端口。端口号请根据实际提示替换。

netstat –anop | grep 54000

根据需要强行停止正在占用端口的进程或者更改数据库监听端口。

问题现象2：

使用gs_om -t status --detail查询集群状态，查询结果如下时，表示主备间连接未建立：

[  Datanode State   ]
node         node_ip         instance                                   state            | node         node_ip         instance                                   state            | node         node_ip         instance                                   state
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1  node1 10.0.0.1    6001 /srv/BigData/hadoop/data2/master1     P Primary Normal | 2  node2 10.0.0.2    6002 /srv/BigData/hadoop/data2/slave1      S Standby Normal | 3  node3 10.0.0.3    3002 /srv/BigData/hadoop/data2/dummyslave1 R Secondary Normal
1  node1 10.0.0.1    6003 /srv/BigData/hadoop/data3/master2     P Primary Normal | 3  node3 10.0.0.3    6004 /srv/BigData/hadoop/data3/slave2      S Standby Normal | 2  node2 10.0.0.2    3003 /srv/BigData/hadoop/data3/dummyslave2 R Secondary Normal
2  node2 10.0.0.2    6005 /srv/BigData/hadoop/data2/master1     P Primary Normal | 3  node3 10.0.0.3    6006 /srv/BigData/hadoop/data2/slave1      S Standby Need repair(Disconnected) | 1  node1 10.0.0.1    3004 /srv/BigData/hadoop/data2/dummyslave1 R Secondary Normal
2  node2 10.0.0.2    6007 /srv/BigData/hadoop/data3/master2     P Primary Normal | 1  node1 10.0.0.1    6008 /srv/BigData/hadoop/data3/slave2      S Standby Need repair(Disconnected) | 3  node3 10.0.0.3    3005 /srv/BigData/hadoop/data3/dummyslave2 R Secondary Normal
3  node3 10.0.0.3    6009 /srv/BigData/hadoop/data2/master1     P Primary Normal | 1  node1 10.0.0.1    6010 /srv/BigData/hadoop/data2/slave1      S Standby Normal | 2  node2 10.0.0.2    3006 /srv/BigData/hadoop/data2/dummyslave1 R Secondary Normal
3  node3 10.0.0.3    6011 /srv/BigData/hadoop/data3/master2     P Primary Normal | 2  node2 10.0.0.2    6012 /srv/BigData/hadoop/data3/slave2      S Standby Normal | 1  node1 10.0.0.1    3007 /srv/BigData/hadoop/data3/dummyslave2 R Secondary Normal

处理办法：

SUSE下，使用chkconfig | grep SuSEfirewall2命令，查看节点上是否开启了防火墙。如果开启，使用SuSEfirewall2 stop命令将其关闭。
Redhat6下，使用service iptables status命令，查看节点上是否开启了防火墙。如果开启，使用service iptables stop关闭防火墙。
Redhat7下，使用systemctl status firewalld.service命令，查看节点上是否开启了防火墙。如果开启，使用systemctl stop firewalld.service关闭防火墙。

集群状态异常

问题现象：

集群某一节点上出现如下问题：

所有实例都是UnKnown。
所有主实例都切换成了备实例。
查询中出现大量Connection reset by peer，Connection timed out等报错信息。

处理办法：

如果ssh不能连接故障机器，在其他机器上使用ping命令向该机器发数据包。如果可以ping通，说明可能是该机器上的资源（内存、CPU、磁盘）耗尽导致不能建立连接。

如果可以连接该机器，尝试执行查询，并每隔1s执行/sbin/ifconfig eth?（?代表数字，表示第几个网卡）命令，查看如下信息中的dropped及errors值的变化情况，如果增长迅速，可能是网卡或网卡驱动故障。

RX packets:6674023192 errors:0 dropped:11114133 overruns:0 frame:580916
TX packets:6464782484 errors:0 dropped:0 overruns:0 carrier:0

检查如下参数设置是否正确：

net.ipv4.tcp_retries1 = 5
net.ipv4.tcp_retries2 = 12

网络连接建立失败

问题现象1：

节点连接其他节点失败，CN或DN的日志中报出“Connection refused”错误。

处理办法：

查看端口是否配置错误，导致连接时使用的端口并非对方监听的端口：查看报错节点配置文件postgresql.conf和系统表pgxc_node中记录端口号是否一致。
查看对方端口监听是否正常（可以使用netstat –anp）。
查看对方进程是否存在。

问题现象2：

对数据库执行SQL操作时，CN获取所有DN的连接描述符失败，报出如下错误：

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

在CN的日志（日志位置请参考日志章节）中，找到上面的错误，并向上查看一段日志内容，可以看到详细的错误信息，常见的错误如下所示，主要是由于主备信息不正确导致。

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 standby mode.

处理办法：

使用gs_om -t status --detail查询集群状态，确认对应的DN状态是否发生过主备切换。具体办法请参考重置实例状态。
此外，需要查看连接失败的节点是否发生了core或者重启。查看是否发生core的办法，请参考core文件。通过om日志可以查看到集群节点是否发生了重启，日志的查看办法请参考日志。

对数据库执行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 10.145.120.79:14600 [Detail:stream connect connect() fail: Connection timed out

或者如下：

ERROR: Distribute Query unable to connect 10.144.192.214:12600 [Detail:receive accept response fail: Connection timed out

处理办法：

使用gs_check检查网络配置是否符合标准。详细参考gs_check中对network的检查。
查看是否有进程发生core或重启，以及主备切换。查看是否发生core的办法，请参考core文件。通过om日志可以查看到集群节点是否发生了重启，日志的查看办法请参考日志。是否发生主备切换的检查办法请参考重置实例状态。
如果不存在上述问题，可以联系网络技术人员做具体分析。

问题现象2：

分布式查询建立连接失败，报错信息如下：

ERROR: Distribute query initializing network connection timeout. Un-connected nodes: dn_6009_6010 dn_6103_6104

处理办法：

参考上面的办法分析网络问题。
查看是否是其他原因导致网络问题，如端口监听线程启动失败等。

连接数据库或执行查询时发生进程停止响应

首先可以通过视图pg_thread_wait_status查看当前查询的等待状态，确定CN在等哪个节点。然后通过视图pgxc_thread_wait_status查看在整个集群节点上的等待状态，确定查询阻塞状态。最后，汇总信息并联系技术支持工程师协助处理。

ITPub博客

故障定位方法-网络故障定位手段

集群启动失败，报网络错误

集群状态异常

网络连接建立失败

对数据库执行SQL操作时，报网络异常中断的错误。

连接数据库或执行查询时发生进程停止响应

最新文章