如果一个数据库集群的一个节点出现故障,会发生什么事情?

如果一个数据库集群的一个节点出现故障,会发生什么事情?,第1张

如果是普通的数据节点宕机,一般不会影响服务。

如果是主节点宕机,如果开启了集群高可用,那么数据库仍会正常提供服务;

如果未开启高可用,那么整个集群就无法对外提供服务了(包括数据库服务)。

2020-08-14

集群有三个成员memberA、B、C成,其中memberB意外故障停掉了,然后memberA 执行stop group_replication退去集群.此时整个集群不可用了(不能更新数据)。

集群中唯一剩余的成员memberC上看到的成员状态为:

但是memberA看到的状态为:

查看最后的存活的memberC的错误日志发现:

"Plugin group_replication reported: 'This server is not able to reach a majority of members in the group. This server will now block all updates. The server will remain blocked until contact with the majority is restored. It is possible to use group_replication_force_members to force a new group membership.' "

大概意思是当前的服务没法获取到成员的投票数,当前服务将会阻塞所有的更新,直到能够获取到投票数。可以使用group_replication_force_members 来强制组成一个新的组。

开始认为这是MGR功能的一个bug,不过后来想想这样的设定也是合理的,因为如果是当前的服务成员自身网络或其他问题导致的无法与其他成员的通信成功,那么这样的情况下这种设定也是合理的,因为不能让它自动重新组成一个组,否则就会可能出现多个重复的组。对于为什么组成员A执行stop group_replication后,剩余的memberC的视图中memberA还是online状态,可能是因为memberB已经unreachable,所以memberC去请求是否同意memberA退去时没有得到结果,一直阻塞等待造成的。此时,memberA的退出结果应该是无法多数投票通过的,因此memberA的退出结果应该是失败的。查看memberA的error日志,结果确实如此:

解决的方法是memberC也执行stop group_replication停掉这个组,再重新组成一个新的组。

此时memberA再重新加入就成功了:

结果:

以此类推,当有多个server组成的group而有多数成员已经意外故障时,导致整个组的停止更新,目前想到的解决的方法就是停掉现在的组,重新组成新的组。

ps:

增加Group Replication System Variables中group_replication_member_expel_timeout的大小,可以避免网络问题或执行事务慢造成的错误驱逐。

这种报错通常是磁盘物理部分扇区损坏。

需要尝试reboot,看能否恢复。

维修、更换磁盘,重做raid,文件系统。数据库做节点替换。

确认服务是否启动

V8

ps -ef|grep corosync

v9

ps -ef|grep gcware

如果服务不存在,且确实没有启动服务,那么请先启动。如果启动了,还是报错或进程不再,请根据后面报错信息排查。

排查

Base 8a 通过strace 排查gcadmin 报错原因

无法连接

这个错误,只有V9才会出现。

服务都没启动

GBase 8a集群常见报错[gcadmin] Could not initialize CRM instance error: [122]->[can not connect to any server]

GC_AIS_ERR_TRY_AGAIN

正常启动后同步REDOLOG

GBase 8a在服务启动后同步REDOLOG数据出现的GC_AIS_ERR_TRY_AGAIN

脑裂

GBase 8a 脑裂导致的gcadmin报错GC_AIS_ERR_TRY_AGAIN

干扰

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

网卡故障

GBase 8a数据库网卡故障导致gcware服务异常

磁盘或内存不足

GBase 8a数据库gcware/corosync服务频繁重启的原因 GC_AIS_ERR_TRY_AGAIN

GBase 8a corosync 日志报错 No space left on device

网络超时

GBase 8a集群常见报错ERROR [CLM ] port_scanning error sockfd:81 time:1(ms) cfg_connect_timeout:5000(ms) error

GC_AIS_ERR_INVALID_PARAM

GBase 8a新安装或扩容后执行SQL报错 Can’t get vcId by distributionId:0, having error:GC_AIS_ERR_INVALID_PARAM

GC_AIS_ERR_NOT_EXIST

GBase 8a 管理命令gcadmin报错GC_AIS_ERR_NOT_EXIST


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/6845747.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-29
下一篇 2023-03-29

发表评论

登录后才能评论

评论列表(0条)

保存