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 监控
在K8S中,worke节点如何加入K8S高可用集群?
在K8S中,worke节点如何加入K8S高可用集群?
|
2月前
|
存储 缓存 Kubernetes
在K8S中,集群节点宕机,可能由哪些原因造成?
在K8S中,集群节点宕机,可能由哪些原因造成?
|
5月前
|
存储 索引
|
存储 关系型数据库 MySQL
pxc_cluster集群
pxc_cluster集群
101 0
|
负载均衡
本篇关于集群
本篇关于集群
104 1
|
存储 NoSQL
Cassandra集群删除宕机节点
Cassandra集群删除宕机节点
Cassandra集群删除宕机节点
|
运维 关系型数据库 MySQL
PXC集群第3个节点无法加入故障处理
PXC集群第3个节点无法加入故障处理
410 0
|
Kubernetes 容器
【k8s】单节点master部署
文章目录 前言 一、部署k8s(二进制) 1.1 架构
336 0
|
云安全 运维 Kubernetes
如何让你的k8s集群更安全
近期在阿里云容器团队与Palo Alto Networks安全团队的联合调研中发现有大量的自建Kubernetes集群存在不同程度的安全隐患,本文主要介绍了Kubernetes集群使用过程中可能遇到的安全风险,同时如何利用阿里云容器服务,容器镜像服务的安全能力和Palo Alto Networks的容器安全解决方案提升Kubernetes集群的整体安全性。
3314 0
如何让你的k8s集群更安全
|
存储 Kubernetes Perl
Pod在多可用区worker节点上的高可用部署
当前很多公有云客户都有通过多可用区部署应用来解决应用高可用或者容灾的相关问题,在kubernetes上也可以通过pod的亲和性和反亲和性将pod分布在不同的可用区,已达到高可用或容灾的目的,本文主要是简单介绍下这种情况下,如何实现pod的多可用区高可用部署。
3334 0