MySQL集群节点宕机，数据库脑裂！如何排障？

MySQL集群节点宕机，数据库脑裂！如何排障？
作者介绍
王晶，中国移动DBA，负责“移动云”业务系统的数据库集成架构设计、运维、优化等⼯作；擅长技术领域MySQL，获Oracle颁发的“MySQL DBA”官⽅认证，熟悉MySQL复制结构、MHA、cluster等多种架构及运维优化。

发现故障的时间正值⼤年初⼆，在各种铺天盖地的拜年信息和微信红包之中，我发现了⼿机上的这条告警通知：
PROBLEM:Disaster: Galera cluster has node down。

我⽣产环境的Galera集群有⼀个节点宕机了。

可能有的⼈不太熟悉MySQL Galera集群，下⾯先介绍⼀下出故障的集群信息。

PXC：
我们⽣产上⽤的是Percona的⼀个MySQL分⽀版本，PerconaXtradb Cluster，简称PXC，这是⼀个可以实时同步的MySQL集群，基于⼴播write set和事务验证来实现多节点同时commit，冲突事务回滚的功能。

强数据⼀致性保证。

Galera Replication原理总结：
1. 事务在本地节点执⾏时采取乐观策略，成功⼴播到所有节点后再做冲突检测；
2. 检测出冲突时，本地事务优先被回滚；
3. 每个节点独⽴、异步执⾏队列中的WS；
4. 事务T在A节点执⾏成功返回客户端后，其他节点保证T⼀定会被执⾏，因此有可能存在延迟，即虚拟同步。

Galera复制的架构图：
Galera flow control：
Galera是同步复制（虚拟同步）⽅案，事务在本地节点（客户端提交事务的节点）上提交成功时，其它节点保证执⾏该事务。

在提交事务时，本地节点把事务复制到所有节点，之后各个节点独⽴异步地进⾏certification test、事务插⼊待执⾏队列、执⾏事务。

然⽽，由于不同节点之间执⾏事务的速度不⼀样，长时间运⾏后，慢节点的待执⾏队列可能会越积越长，最终可能导致事务丢失。

Galera内部实现了flow control，作⽤就是协调各个节点，保证所有节点执⾏事务的速度⼤于队列增长速度，从⽽避免丢失事务。

实现原理很简单。

整个Galera Cluster中，同时只有⼀个节点可以⼴播消息（数据），每个节点都会获得⼴播消息的机会（获得机会后也可以不⼴播），当慢节点的待执⾏队列超过⼀定长度后，它会⼴播⼀个FC_PAUSE消息，所以节点收到消息后都会暂缓⼴播消息，直到该慢节点的待执⾏队列长度减⼩到⼀定长度后，Galera Cluster数据同步⼜开始恢复。

搞清楚上⾯的背景原理之后，继续说明我的排障过程。

问题描述
1⽉29⽇早10点08分接收到Zabbix告警信息，⽣产环境某⼦系统数据库集群节点1、2分别报活跃线程数超阀值，⽽且不断升⾼。

从业务侧尝试访问了⼀下该⼦系统，发现系统页⾯⼀直⽆法正常查询数据及修改数据。

登陆服务器查看CPU、IO、内存情况均空闲。

说明累计的活跃线程过⾼，已经影响到业务的正常访问了。

问题分析
1、登陆Zabbix告警节点1、2查看数据库show global status like ‘Threads_running’情况发现Threads_running线程不断增⾼。

节点1：
| Threads_running| 100 |
节点2：
| Threads_running| 110 |
2、继续查看节点1、2数据库的show processlist的情况，发现存在很多线程停在wsrep in pre-commit stage状态(这意味着很多线程已经在节点发出commit，但将该SQL发送到其他节点是处于独⽴异步地进⾏certification test、事务插⼊待执⾏队列的状态）。

这⾥就明了为什么会有活跃线程不断增加了，原来是线程都停留在wsrep in pre-commit stage状态。

3、进⼀步查找为什么会有线程⼀直停留在wsrep in pre-commit stage状态，show global status like ‘%wsrep%’，发现1、2节点接受队列并
⽆阻塞，也没有发出流控。

但wsrep_evs_delayed报节点3的4567端⼝连接延迟。

查看节点1、2错误⽇志发现报“WSREP: (40a252ac, ‘tcp://节点2:4567’) reconnecting to 67f667d2 (tcp://节点3:4567), attempt 0”。

查看节点3的错误⽇志与wsrep_evs_delayed运⾏参数则报相反信息，连接节点1和节点2的4567端⼝延迟。

这⾥需要解释⼀下4567端⼝的作⽤(wsrep_provider_options中的gmcast.listen_addr项：主要作⽤是集群内监听组员状态，组员之间的通信(握⼿，鉴权，⼴播，写⼊集的复制)。

此时，问题原因已经明朗了，因为节点3与节点1、2的4567端⼝⼀直连接有延迟，所以在节点1、2执⾏的请求⽆法及时的复制给节点3执⾏，导致节点1、2的活跃线程⼀直执⾏不完。

节点1：
+——————————+————-+
| Variable_name | Value |
+——————————+————-+
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_avg | 0.008711 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_evs_delayed | 节点3:4567 |
+——————————+————-+
节点2：
+——————————+————-+
| Variable_name | Value |
+——————————+————-+
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_avg | 0.006193 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_evs_delayed |节点3:4567 |
+——————————+————-+
4、因查询数据库状态除wsrep_evs_delayed报连接延迟，其他并⽆异常现象，初步怀疑是⽹络原因造成，排查⽹络后，发现是因核⼼交换机与接⼊交换机之间的光模块损坏导致丢包，所以影响部分数据库集群之间的通信，才会出现以上问题。

在⽹络修复期间，因数据库集群节点3延迟丢包严重，被数据库集群仲裁后踢出了集群，剩余的节点1和节点2在运⾏了⼤约半⼩时后也因延迟丢包严重，出现了脑裂现象。

这时紧急将数据库集群3个节点关闭，然后在每个节点执⾏mysqld_safe –wsrep-recover命令找出最新事务号节点作为主节点启动，并在故障期间保持单节点运⾏。

待⽹络故障消除后，逐⼀启动节点2、3，系统数据库集群恢复正常。

问题回顾
1、在PXC环境中，如果集群各个节点的通信端⼝(4567)因为⽹络的原因出现异常（因为集群节点间通信采⽤的是同⼀⽹段，因此是共性的原因），应及时采取相应措施防⽌脑裂情况出现。

例如上⾯故障中，因⽹络原因导致集群节点数从3个变为2个，这时就应该及时地关闭剩余2个节点中的⼀个节点，让业务只跑在单节点上，还能避免出现脑裂的情况。

⾄少业务不会因此终断。

否则剩余的两个节点很快也会被⽹络丢包拖垮，会导致整个集群都停⽌服务，影响业务。

当然在⾮多主的集群中也可以通过设
置“SET GLOBAL wsrep_provider_options=’pc.ignore_sb=true’;”来取消集群判断脑裂的情况(多主环境中不建议使⽤)。

2、可以将wsrep_evs_delayed作为⼀个监控项进⾏监控，并结合⽹络监控进⾏适当的告警。