PXC集群脑裂导致节点是无法加入无主的集群

简介: PXC集群脑裂导致节点是无法加入无主的集群

一套2节点的MySQL PXC集群,第1节点作为主用节点长时间的dml操作,导致大量的事务阻塞,出现异常,此时查看第2节点显示是primary状态,但无事务阻塞情况。
此时第1节点无法正常提供服务,于是以为第2节点可以作为主节点提供sst数据源来新建第1节点,但清空第1节点开始启动时,却发现无法正常启动sst同步,因为:failed to reach primary view
此时的报错信息详情如下:

2022-03-16T11:28:00.546024Z 0 [ERROR] [MY-000000] [Galera] failed to open gcomm backend connection: 110: failed to reach primary view (pc.wait_prim_timeout): 110 (Connection timed out)
         at gcomm/src/pc.cpp:connect():161
2022-03-16T11:28:00.546105Z 0 [ERROR] [MY-000000] [Galera] gcs/src/gcs_core.cpp:gcs_core_open():220: Failed to open backend connection: -110 (Connection timed out)
2022-03-16T11:28:01.546361Z 0 [Note] [MY-000000] [Galera] gcomm: terminating thread
2022-03-16T11:28:01.546471Z 0 [Note] [MY-000000] [Galera] gcomm: joining thread
2022-03-16T11:28:01.546783Z 0 [ERROR] [MY-000000] [Galera] gcs/src/gcs.cpp:gcs_open():1754: Failed to open channel 'pxc-cluster' at 'gcomm://133.95.34.245,133.95.34.246,133.95.34.250': -110 (Connection timed out)
2022-03-16T11:28:01.546831Z 0 [ERROR] [MY-000000] [Galera] gcs connect failed: Connection timed out
2022-03-16T11:28:01.546868Z 0 [ERROR] [MY-000000] [WSREP] Provider/Node (gcomm://133.95.34.245,133.95.34.246,133.95.34.250) failed to establish connection with cluster (reason: 7)
2022-03-16T11:28:01.546903Z 0 [ERROR] [MY-010119] [Server] Aborting

那么比较合理的解释是,异常导致集群发生脑裂,虽然第2节点显示是primary,但无法提供sst同步给其他节点,此时只能将第2节点作为bootstrap服务重启,成为真正的主节点,即可正常启动同步第1节点。
那么此时问题的关键是,第2节点无法提供sst数据同步时的判断依据到底是什么呢?
以上,留作参考。

目录
相关文章
|
2月前
|
Kubernetes 应用服务中间件 Linux
多Master节点的k8s集群部署
多Master节点的k8s集群部署
|
4月前
|
存储 Kubernetes 监控
在K8S中,worke节点如何加入K8S高可用集群?
在K8S中,worke节点如何加入K8S高可用集群?
|
4月前
|
存储 缓存 Kubernetes
在K8S中,集群节点宕机,可能由哪些原因造成?
在K8S中,集群节点宕机,可能由哪些原因造成?
|
7月前
|
存储 索引
|
存储 关系型数据库 MySQL
pxc_cluster集群
pxc_cluster集群
114 0
|
负载均衡
本篇关于集群
本篇关于集群
115 1
|
存储 NoSQL
Cassandra集群删除宕机节点
Cassandra集群删除宕机节点
Cassandra集群删除宕机节点
|
NoSQL Redis 开发者
集群-主从下线与主从切换|学习笔记
快速学习集群-主从下线与主从切换
|
运维 关系型数据库 MySQL
PXC集群第3个节点无法加入故障处理
PXC集群第3个节点无法加入故障处理
441 0
|
云安全 运维 Kubernetes
如何让你的k8s集群更安全
近期在阿里云容器团队与Palo Alto Networks安全团队的联合调研中发现有大量的自建Kubernetes集群存在不同程度的安全隐患,本文主要介绍了Kubernetes集群使用过程中可能遇到的安全风险,同时如何利用阿里云容器服务,容器镜像服务的安全能力和Palo Alto Networks的容器安全解决方案提升Kubernetes集群的整体安全性。
3362 0
如何让你的k8s集群更安全