集群节点能ping通,但无法通过ssh连到节点,通过gncli也无法连到数据库,导致集群下发SQL时一直试图连接到该节点。长时间处于这种状态下导致大量SQL积压。如何解决?

方法1:
到机房关闭故障节点的gcware服务或者将服务器关机、断开网络连接。待设备问题解决后再连入集群。
方法2:
在无法到机房操作服务器的情况下,需要通过集群层命令从集群中将故障节点暂时离线,待故障解决后再恢复为正常状态。
操作方法:使用gcadmin setnodestate设置节点failure离线状态解决。
setnodestate命令语法:gcadmin setnodestate ip <state>
ip:要设置状态的节点ip;
State: 设置后的节点状态:

  • UNAVILIABLE:用于节点替换。
  • failure:标识集群故障,相当于offline 这时dml、ddl将不会下发到该节点直接记录fevent;
  • normal:当节点故障解决后可以直接将节点置为normal,这相当于节点重新online,这时gcrecover将恢复之前记录的feventlog,新发起的ddl、dml将重新下发到该节点。
    [info]注:[/info]

集群存在多个distribution时,如果设置一个节点为unavailable状态,会导致任何一个distribution中出现某个分片的主副分片都不可用得情况,则设置失败。

gcware如何知道各个节点的状态

gcware使用ssh探测各个节点的状态,使用ssh探测是使用默认的22端口,如果ssh端口号修改了,就要对应修改corosync配置文件中的配置参数。

检查gcware内探测节点状态所使用的ssh端口与系统的ssh端口是否一致的方法为:
首先执行cat /etc/corosync/corosync.conf命令查看corosync配置文件中的node_ssh_port端口,如果配置文件中没有node_ssh_port端口,表示程序默认使用22端口;
然后执行cat /etc/ssh/sshd_config命令,查看系统ssh服务所使用的端口。

修改gcware内探测节点状态所使用的ssh端口与系统的ssh端口是否一致的方法为:

方法1:
修改/etc/corosync/corosync.conf配置文件中的node_ssh_port端口,使其与/etc/ssh/sshd_config中的Port一致。

方法2:
修改/etc/ssh/sshd_config中的Port端口,修改命令包含如下三条:
(1)执行vi /etc/ssh/sshd_config(修改ssh服务端端口)命令,将Port端口修改为/etc/corosync/corosync.conf配置文件中的node_ssh_port端口。
(2)执行vi /etc/ssh/ssh_config(修改ssh客户端端口)命令,将Port端口修改为/etc/corosync/corosync.conf配置文件中的node_ssh_port端口。
(3)执行/etc/init.d/sshd restart命令,重启ssh服务。

集群正常是通过root启停服务,是否可以使用gbase启停服务?

单独的重启除corosync外的集群组件,可以使用gbase用户操作,具体为:

gcluster_services  <gbase | gcluster | gcrecover | syncserver | all>  start|stop

corosync和gcware,需要root用户权限;

另外,可以配置gbase用户的sudo,可以在不用su - root的情况下使用gbase用户执行sudo service gcware stop|start来实现gcware服务的启停。

集群搭建中是否允许一台主机有两个或多个网络接口配置为同一网段?

这种配置需要避免,主要原因为:
(1)OS一般不建议这么配置网络,而这种配置的通讯会取决于路由的配置,一般OS会只配置第一个接口去与同网段的其它主机通讯;
(2)gcware在绑定通讯接口过程中,会绑定与配置文件中指定地址同一个网段第一个地址,所以有可能会绑定的接口与指定接口不一致,
而导致NODEID(每个gcware的标示)与设定不一致,显示的信息会错误,在网络MASK设置不当的情况下还会出现集群分裂。