GBase有奖征文优选文章10 | GBase 8a V95集群gcware常见问题排查手册

Original 袁清乾 GBASE数据库

2024-11-02

GBase 8a V95集群gcware常见问题排查手册

文 | 袁清乾

编写目的

GBase 8a V95版本的集群一致性服务gcware与V86版本比有很大改变，基础协议从虚同步协议改为Raft协议，集群的高可用性得到了更大的提升。

不同现场部署时，不可避免的由于服务器、网络等环境差异导致的一些部署上的问题，通过这篇文章对常见的问题及排查方法进行总结，方便客户现场更快速的定位问题。

适合对象

重点面向技术支持、测试人员。

现象描述、原因分析及解决办法

执行gcadmin卡住

现象描述

执行gcadmin，长时间不返回，如下图所示。

原因分析

1. 检查各个coor节点(V952)或者gcware(V953)节点的gcware服务是否启动

通过ps -ef|grep gcware查看gcware服务是否启动，下图信息表示gcware服务未启动

解决办法：

V952版本：gcluster_services all start

V953版本：gcware_services all start

下图表示gcware服务正常启动

2. 检查防火墙是否关闭

查看各个coor节点的gcware.log，发现一直在刷下面的日志，“vote req from”表示在不停的发起选举，2160502976表示本节点的nodeid，且nodeid一直是同一个，即每个节点的gcware服务只能收到自己的投票信息，出现这种情况，表示系统的防火墙未关闭。

解决办法：

（1）客户现场如果允许关闭防火墙，则通过系统命令关闭防火墙解决。

（2）客户端现场如果不允许关闭防火墙，则需要设置防火墙规则，允许5918和5919端口的tcp和udp消息正常通信，其中5918端口用于不同节点gcware服务之间通信，比如leader选举、数据同步、心跳消息，5919端口用于gcluster服务访问gcware服务。

3. 一个gcware节点被同时添加到多个集群中

通过cat $GCWARE_BASE/config/gcware.conf命令查看配置文件中member包含的成员ip

在其中一个节点上通过tcpdump -i eth0 port 5918命令抓包，查看是否存在不属于member列表中ip的消息，如下图所示，收到了不属于member列表的消息。

解决办法：

停止集群服务，修改$GCWARE_BASE/config/gcware.conf配置文件，确保一个gcware节点只被加到一个集群中，之后重启集群服务即可。

4. 集群中feventlog数量达到几十万，引起gcware分裂

查看gcware.log，可以正常收到其他节点gcware服务发送的消息，选出leader后，过一会又分裂，执行gcadmin命令，一会能正常返回，一会又卡住。

执行gcadmin showddlevent、gcadmin showdmlevent和gcadmin showdmlstorageevent查看集群中是否包含几十万条feventlog。

解决办法：

（1）部分feventlog不重要，可以通过gcadmin rmfeventlog ip命令删除

（2）集群部署了多个coordinator节点时，先执行gcmonit.sh stop命令将各个coordinator节点的监控服务停掉，然后执行gcluster_services gcrecover stop命令，只剩下一个或几个coordinator节点上的gcrecover服务，具体剩下几个，根据不再引起gcware分裂为止。

（3）以上2点还解决不了问题，需反馈给南大通用技术支持或者拨打电话：400-013-9696，寻求技术解决。

gcadmin显示其中一个gcware服务的状态

为CLOSE

现象描述

查看gcware服务的进程号在不停的变，如下图所示：

查看gcware.log，看到“raft node init fail”关键字。

原因分析

gcluster访问gcware写入的信息，比如scn、tableid、lock、failover和feventlog等信息先写入REDOLOG，达到10万条或者REDOLOG文件大小达到512MB时，会将REDOLOG中的信息刷到SNAPSHOT中，当服务器异常断电时，可能会存在REDOLOG文件损坏的情况，这时会导致gcware服务无法正常启动。

解决办法

1. 集群中部署了多个gcware服务节点

可以通过从leader节点拷贝gcware持久化目录的方式恢复，详细说明如下：

（1）在各个gcware节点执行grep -E "switch to leader" $GCWARE_BASE/log/gcware.log命令，“switch to leader with term:”关键字后，数据大的节点为leader节点，如下图所示，看到term最大的是1004，表示nodeid为2328275136的节点为leader节点。

（2）停止REDOLOG文件损坏节点的gcware服务，并将$GCWARE_BASE/data/gcware目录mv走，之后将leader节点的整个$GCWARE_BASE/data/gcware目录拷贝到REDOLOG文件损坏的节点上，最后启动REDOLOG文件损坏节点的gcware服务即可。

2. 集群中只部署了一个gcware服务节点

由于只有一个gcware节点，没有高可用，所以出现REDOLOG文件损坏时，无法通过从其他好的节点拷贝持久化文件的方式来恢复，只能通过删除最后一个损坏的REDOLOG文件的方式恢复，可能会丢失一些信息，比如feventlog或者failover导致集群服务恢复正常后，数据不一致，恢复方法如下。

（1）停止集群所有服务。

（2）执行ll $GCWARE_BASE/data/gcware/命令，找到该目录下REDOLOG后面编号最大的那个，这里最大的是REDOLOG.79。

（3）删除REDOLOG编号最大的文件。

（4）通过gcluster_services gcware start（V952）或gcware_services gcware start（V953）命令，只启动gcware服务。

（5）待gcadmin正常返回后，通过gcware的python接口将scn和tableid初始化为更大的值，避免由于REDOLOG文件中记录了之前申请过的scn或tableid，导致新建的表与原有的表tableid或scn重复，命令如下。

[gbase@localhost data]$ python

Python 2.7.5 (default, Apr 2 2020, 13:16:51)

[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> import gcware

>>> gcware.getscn() 获取当前scn

100000