Galera Cluster中节点异常宕机排查

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 背景在Group Replication发布之前,MySQL官方复制有异步、半同步。当时弥补全同步的方案,大多数公司会选择Galera cluster,主要有percona server的PXC和MariaDB的MGC两种版本,而且都嵌入到各自的版本中。

背景

在Group Replication发布之前,MySQL官方复制有异步、半同步。当时弥补全同步的方案,大多数公司会选择Galera cluster,主要有percona server的PXC和MariaDB的MGC两种版本,而且都嵌入到各自的版本中。本文针对客户生产环境使用Galera Cluster(MGC)遇到的一则宕机案例

环境信息

  • MariaDB 10.0.15
  • redhat 6.5

日志信息

节点二(正常)日志:

190308 17:08:43 [Note] WSREP: Member 0.0 (node23) requested state transfer from '*any*'. Selected 1.0 (node144)(SYNCED) as donor.
190308 17:08:43 [Note] WSREP: Shifting SYNCED -> DONOR/DESYNCED (TO: 397258687)
190308 17:08:43 [Note] WSREP: IST request: a6befc67-f455-11e6-a8e6-fa93a785f2f6:397258655-397258656|tcp://21.244.57.46:4568
190308 17:08:43 [Note] WSREP: IST first seqno 397258656 not found from cache, falling back to SST
190308 17:08:43 [Warning] WSREP: SST request is null, SST canceled.

节点三(宕机)日志:

190308 17:08:43 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 397258687)
190308 17:08:43 [Note] WSREP: Requesting state transfer: success after 2 tries, donor: 1
190308 17:08:43 [Note] WSREP: GCache DEBUG: RingBuffer::seqno_reset(): discarded 0 bytes
190308 17:08:43 [Note] WSREP: GCache DEBUG: RingBuffer::seqno_reset(): found 1/31 locked buffers
190308 17:08:43 [Warning] WSREP: 1.0 (node144): State transfer to 0.0 (node23) failed: -125 (Operation canceled)
190308 17:08:43 [ERROR] WSREP: gcs/src/gcs_group.c:gcs_group_handle_join_msg():723: Will never receive state. Need to abort.

总结:

  • 节点二所在的MySQL实例作为节点三的donor;而且从节点二日志可以看出:事务a6befc67-f455-11e6-a8e6-fa93a785f2f6:397258655-397258656已经不在gcache中(丢失),从而导致节点三IST失败,只能重新启动节点三MySQL实例,通过SST来全量同步重新加入集群。

建议:

  • 调大参数gcache.size的值,使得gcache中能够存储更多的事务
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
6月前
|
运维 负载均衡 监控
解析ProxySQL的故障转移机制
解析ProxySQL的故障转移机制
202 0
|
7月前
|
Kubernetes 容器
k8s集群部署成功后某个节点突然出现notready状态的问题原因分析和解决办法
k8s集群部署成功后某个节点突然出现notready状态的问题原因分析和解决办法
408 0
|
SQL 关系型数据库 MySQL
只读实例(slave主从)延迟排查
本文分享的方法适用于实时查看只读延迟(主从延迟),即需要在延迟发生的时候查看才能确认问题,历史延迟不适用,以下环境已经开启并行复制。
只读实例(slave主从)延迟排查
|
运维 关系型数据库 MySQL
PXC集群第3个节点无法加入故障处理
PXC集群第3个节点无法加入故障处理
441 0
|
Go API 开发工具
利用etcd选举sdk实践master/slave故障转移
本次记录[利用etcd选主sdk实践master/slave故障转移], 并利用etcdctl客户端验证选主sdk的工作原理。
利用etcd选举sdk实践master/slave故障转移
|
NoSQL 算法 Java
Redis Cluster 宕机引发的事故(上)
Redis Cluster 宕机引发的事故(上)导读: Redis官方号称支持并发11万读操作,并发8万写操作。由于优异的性能和方便的操作,相信很多人都在项目中都使用了Redis,为了不让应用过分的依赖 Redis服务,Redis的作用只作为提升应用并发和降低应用响应时间存在,即使Redis出现异常,应用程序也不应该出现提供服务失败问题,对此拍拍信最近安排了一次全环境的Redis Cluster 宕机演练。 本文作者系拍拍信架构负责人朱荣松和拍拍信架构开发工程师许彬,授权“技术锁话”进行发布。
361 0
Redis Cluster 宕机引发的事故(上)
|
NoSQL Java Redis
Redis Cluster 宕机引发的事故(下)
Redis Cluster 宕机引发的事故(下)
739 0
Redis Cluster 宕机引发的事故(下)
|
Kubernetes 容器 Perl
K8S重新加入master节点时如何避免etcd报错
我们有时候会有删除节点,再重新加入master节点的需求,比如master机器改名。这里注意重新加入时,经常会出现etcd报错,这个时候就需要去还没有停止的master节点里的etcd的pod里去,删除该老master节点对应的etcd信息。
1997 0
|
NoSQL Redis Java
Redis-Cluster实战--13.redis Cluster故障转移(failover)
转载请注明出处哈   一、测试环境 1. Redis版本:     由于我们较早的使用了Redis-Cluster版本,所以此测试使用的是Redis 3.0.0 RC1 (version 2.9.101)   后来有开发者提出,如果是大集群的话,会造成判定失败过慢,造成failover失败,所以作者在Redis 3.0.0 RC3做了修正,当然现在的release版已经不存在这个问题了。
2032 0
Redis-Cluster实战--13.redis Cluster故障转移(failover)