一例rmt导出报16066端口connection refused问题经验分享

1. 问题描述

使用gccli -h方式连接远程数据库，rmt导出文件报错，报16066端口connection refused

2.环境

3.问题分析过程

3.1网络检查：

检查网络无问题，通过ping 、tracert、telnet端口、防火墙、selinux等，网络未发现异常；

3.2版本检查：

更换gccli版本后现象依旧；gccli连接另外一套集群，可以使用rmt正常导出，基本可判定gccli客户端无问题；服务端使用节点自带的gccli -h的方式，rmt导出功能也正常，服务端版本问题排除。

gccli 连接另外一套集群，rmt导出正常

用节点自带的gccli -h方式，rmt导出正常

3.3 gccli日志检查:

通过remote_export_debug=1参数，打开gccli日志，bind 16066端口成功，建立lisening，未发现gccli客户端日志有什么异常；

3.4连接检查：

a) gccli -h连接服务端后，在服务端使用netstat -anop | grep gclusterd ，检查服务端口连接情况，发现gclusterd 的端口是5258，而不是gccli连接时指定的-P25258.

b) 检查25258端口，为ssh服务；

c) 检查5258端口，为gcluterd服务；

d）gccli -h 不带端口后，rmt功能恢复正常。

e) 问题原因：数据库的默认端口5258，部分客户由于安全原因，需要修改默认端口，而客户使用的是ssh端口映射的方式，而不是修改的gclusterd的端口，gclusterd反向查询gccli的ip时，未获取到gccli的ip，导致出错。

4.总结

4.1 rmt导出的功能原理及本次错误原因

正常情况下，A（gccli）通过-h的方式，连接到B（集群协调节点），B通过反向查询，获取A的IP，并通知所有节点（node1 – node5），将数据发送给A，而不在通过B中转；当B反向查询无法获取A的IP时，会将B的IP通知所有节点发送数据，就出现了本案例中，出现的节点连接B的16066端口refused情况，由于发起rmt任务（16066）的A机器，B机器上就没有16066的服务，连接这个端口会报connect refused 错误。

4.2 以下错误信息可帮助初步排查错误：

a）报连接B 16066端口connection refused（本案例），连接的IP就错误，原因可能是B反向查询A的ip未查询到，导致计算节点连接的ip连错了，可排查是不是端口映射的问题；

b) 连接报no route to host，则是gccli客户端的16066端口未开放，连接不成功。远程导出的端口为16066-16166，需要在gccli客户端的机器上，设置端口白名单（firewall-cmd --permanent --zone=public --add-port=16066-16166/tcp）。

4.3 正常的数据库端口修订方式（参考产品手册）

• gcluster端口5258可以更改，在集群的所有节点上进行如下操作：

1) 使用dbauser用户修改$GCLUSTER_BASE/config/gbase_8a_gcluster.cnf文件中相关内容，具体修改参数如下：

[client]

port=5258

socket=/tmp/gcluster_5258.sock

[gbased]

socket=/tmp/gcluster_5258.sock

port=5258

2) 需要将5258修改为新的端口号，具体如下：

# su - gbase

$ vi $GCLUSTER_BASE /config/gbase_8a_gcluster.cnf

[client]

port=5259

socket=/tmp/gcluster_5259.sock

...

[gbased]

...

socket=/tmp/gcluster_5259.sock

...

port=5259

...

3) 各个节点上的配置文件修改后，重新启动gcware服务。

4) 使用root用户，验证新端口设置成功。

$ su - root

密码：

# lsof -i:5259

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME

gclusterd 4780 gbase   14u IPv4  23640      0t0 TCP *:5259 (LISTEN)