南大通用GBase 8a 集群服务处于CLOSE状态常见原因汇总

GBase 8a MPP 集群,可以通过gcadmin命令查看每个节点的服务状态。正常情况下,应为OPEN。本文重点介绍gclusterd和gbased两个服务常见的几种会到导致服务为CLOSE的原因。

例子

gcware正常,gcluster和gnode都显示CLOSE状态

服务检测相关问题

GBase8a的服务检测有超时配置,默认5秒,如果超过了还没有正常返回,则判断服务故障CLOSE。

此类问题是服务本身没问题,是正常运行的,但由于网络,负载等相关的环境出现故障。导致检测服务异常。

防火墙

这个在初始安装,或者现场做过安全加固后最常见。

现象

最常见的时互相看对方为CLOSE,而自己为OPEN.

比如A,B两个节点,在A节点看,自己是OPEN的,而B上服务都是CLOSE;而在B节点看,自己是OPEN,而A是CLOSE。

对于V8版本集群,一般伴随着集群状态为LOCK。

如果是V95集群,可能伴随着gcadmin命令长时间不返回现象。

解决方法:

  查看防护墙/selinux是否关闭。

脑裂

常见于V8版本,V9未见过。

一般是corosync配置的节点数较多(20+)场景。所有管理节点同时启动服务时,有概率会发生。管理节点越多,几率越高。

当然网络如果偶发抖动,也可能产生这个现象,但概率极低。

现象

服务状态偶发的出现CLOSE, 但有时又能显示OPEN。

解决方法:

  将带有corosync/gcware服务全部停止 stop,然后再逐台启动 start,不是重启restart。

网路差

  网络设备问题,包括网卡,网线,交换机等。

现象:

  服务状态也是时好时坏。但一般会持续很长时间。

  ping或者scp传输数据性能差。

  也出现过网卡,降速到10M或100M了。

  gcware日志里,有cfg_connect_timeout报错字样。

解决方法

 排查网络故障。

服务器负载高

  服务器负载高,特别是磁盘,会导致在检测周期内没有及时响应,超时判断为CLOSE。

现象:

  大部分是个别节点,或者一批类似的服务器。

  常见于偶发CLOSE,其它时间是OPEN

  查看机器资源,CPU/磁盘长时间100%,其中磁盘的await高于100ms. 如下是一个awai达到5秒以上的例子。

gcware日志里,有cfg_connect_timeout报错字样。

解决方法

  排查负载高的原因。

  可尝试reboot排除操作系统问题。

  如果是磁盘问题,建议停服务后测试fio。

  见过RAID卡没有内存,性能极差。

  CPU降速。

服务干扰

其它机器,安装过数据库服务,但停用后,没有卸载干净,IP也变了。 一旦服务启动,会干扰现有IP的服务。

现象

服务时好时坏,但持续不断,间隔很短。

逐个管理节点运行tcpdump 会看到不输入集群IP的节点发来数据包。

参考:GBase 8a 集群服务corosync、gcware由于其它IP干扰导致异常

解决方案

找到干扰集群,卸载集群或者删除gcware配置文件。 比如86版本的 /etc/corosync/corosync.conf,95版本的安装目录/gcware/conf/gcware.conf

服务无法启动

  这个就是服务本身出问题,无法启动。常见于系统做了变动,比如改了操作系统参数,数据库参数,本机环境出问题等。

  一般服务多次restart, 甚至服务器reboot后,依然还无法恢复的,算服务无法正常启动了。

数据库参数问题

  常见于参数不存在,参数值配置错误等。

现象:

  数据库的system.log日志里,会给出不支持的参数或参数值的报错信息。

  也可以手工执行gclusterd,看到错误信息。如下是一个参数值设置错误的例子。

  常见于版本打过补丁。

解决方法

  根据报错内容,修正参数。

数据库权限问题

  数据库相关程序不能在777权限下,特别是config下的配置文件。

  另外,所有可执行文件,必须有x可执行权限。

现象:

  查看system.log会发现某些不符合要求的程序或文件。 而默认的配置,少了某些参数,可能导致服务无法启动。  

  手工运行gclusterd,会报permission deny。

解决方法

  设置数据库配置文件640或600权限

  查看可执行文件,增加x权限。

数据库运行用户问题

  V95版本不能在操作系统用户root下运行,启动会报错。

现象

  用操作系统root用户启动,发现服务一直无法正常运行。

  手工执行gclusterd或者gbased报错,显示不能以root运行

解决方法

  切换到dbaUser下启动服务。

数据库文件属主问题

  所有数据库文件的属主必须是dbaUser, 但如果用户重建过dbaUser(删除用户,再建立用户,uid会变化),会导致原有的数据库文件的属主错误,导致无法访问

现象

  数据库目录和文件,无法通过dbaUser访问。用root用户查看文件属主,一般会出现数字。

数据库安装目录的宿主丢失,变成了1034,而用户组还是gbase。

解决方案

  通过chown  -R 修改成正确的属主。

环境变量问题

  环境变量一般放在dbauser下的.gbase_profile里,并通过.bash_profile调用。

  如果环境变量被破坏,则可能导致服务运行的环境变量错误,导致服务无法启动。

  常见于安全加固,或者安装了客户端且修改了环境变量的场景。

现象

  查看.bash_profile文件和.gbase_profile,发现内容错误。比如目录不匹配。

解决方案

 如果只是部分节点,可以从正常的节点复制一份。

 如果全部损坏,可以从其它集群复制一份,然后按照本地目录做编辑调整。

PID文件问题

数据库启动后,会在log目录下生成pid文件,比如

/opt/gnode/log/gbase/gbased.pid

该文件的内容,为进程号。比如gbased的进程1234, 则这个pid文件里保存的就是1234。

如果该文件已经存在,且对应的进程(/proc/1234)也存在,则表示已经有一个进程运行中。

现象

手工运行gbased时,报错 have another program is running

运行strace gbased可以看到检测过程

  • 1、查看pid文件是否存在,如不存在,则正常继续了
  • 2、如已存在,则打开文件,读取文件内容。如下图中为2363
  • 3、检查/proc/2363是否已经存在,如已在,则表示已经有进程在运行中。

查看/proc/2363,确实已经存在了

解决方法

删除pid文件即可。

数据文件损坏

由于系统宕机,断电,磁盘空间满等,导致数据文件没有正确的写入内容。在启动时,没有考虑到某些异常情况,导致启动失败。

常见于:

1、RAID没有电池的物理机,虚拟机,云主机等断电;

2、磁盘空间满且维持很长一段时间(分钟以上),数据库默认的守护进程gcmonit在发现进程(主要是gcware/corosync)消失后,只会自动拉起有限次数(默认10次,可修改gcmonit.conf调整参数),如果都没有成功,即使后面空间释放了,进程也不会自动拉起来。

总结

一个稳定运行的环境,出现服务CLOSE问题,多见于环境变动。根据服务是否真的无法启动,来分别处理。