网络故障定位手段
通信网络层是分布式数据库的基础组件，在数据库正常工作的情况下，网络层对上层用户是透明的，但分布式集群数据库在长期运行时，可能会由于各种原因导致出现网络异常或错误。
GaussDB 200常见的因网络故障引发的异常有：
- 集群启动失败，报网络错误。
- 集群状态异常，如：节点上所有的实例都是UnKnown或者所有主机都切换为备机。
- 网络连接建立失败。
- 对数据库执行SQL操作时，报网络异常中断的错误。
- 连接数据库或执行查询时发生进程停止响应。
分布式数据库出现了网络故障后，主要通过使用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处理办法：
- 登录FusionInsight Manager界面，查看服务器是否开启了防火墙。
单击“主机”，再单击指定的主机名称。
在“基本信息”中查看“防火墙”状态，“ON”表示开启了防火墙，“OFF”表示没有开启。
- 如果开启了防火墙，则使用以下方法将其关闭。
- Linux下，使用SuSEfirewall2 stop命令将其关闭。
- RedHat 6下，使用service iptables stop关闭防火墙。
- RedHat 7下，使用systemctl disable firewall关闭防火墙。
集群状态异常
问题现象：
集群某一节点上出现如下问题：
- 所有实例都是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查看在整个集群节点上的等待状态，确定查询阻塞状态。最后，汇总信息并联系技术支持工程师协助处理。
查看更多：华为GaussDB 200 故障定位方法「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」关注作者【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。评论
