MySQL集群节点宕机,数据库脑裂!如何排障?

BellGolding 7年前
   <p>发现故障的时间正值大年初二,在各种铺天盖地的拜年信息和微信红包之中,我发现了手机上的这条告警通知:</p>    <p>PROBLEM:Disaster: Galera cluster has node down。我生产环境的Galera集群有一个节点宕机了。</p>    <p>可能有的人不太熟悉MySQL Galera集群,下面先介绍一下出故障的集群信息。</p>    <p>PXC:</p>    <p>我们生产上用的是Percona的一个MySQL分支版本,PerconaXtradb Cluster,简称PXC,这是一个可以实时同步的MySQL集群,基于广播write set和事务验证来实现多节点同时commit,冲突事务回滚的功能。强数据一致性保证。</p>    <p>Galera Replication原理总结:</p>    <p>1. 事务在本地节点执行时采取乐观策略,成功广播到所有节点后再做冲突检测;</p>    <p>2. 检测出冲突时,本地事务优先被回滚;</p>    <p>3. 每个节点独立、异步执行队列中的WS;</p>    <p>4. 事务T在A节点执行成功返回客户端后,其他节点保证T一定会被执行,因此有可能存在延迟,即虚拟同步。</p>    <p>Galera复制的架构图:</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/6cefe6b3333fabe3c8717490b48b092f.jpg"></p>    <p>Galera flow control:</p>    <p>Galera是同步复制(虚拟同步)方案,事务在本地节点(客户端提交事务的节点)上提交成功时,其它节点保证执行该事务。在提交事务时,本地节点把事务复制到所有节点,之后各个节点独立异步地进行certification test、事务插入待执行队列、执行事务。然而,由于不同节点之间执行事务的速度不一样,长时间运行后,慢节点的待执行队列可能会越积越长,最终可能导致事务丢失。</p>    <p>Galera内部实现了flow control,作用就是协调各个节点,保证所有节点执行事务的速度大于队列增长速度,从而避免丢失事务。</p>    <p>实现原理很简单。整个Galera Cluster中,同时只有一个节点可以广播消息(数据),每个节点都会获得广播消息的机会(获得机会后也可以不广播),当慢节点的待执行队列超过一定长度后,它会广播一个FC_PAUSE消息,所以节点收到消息后都会暂缓广播消息,直到该慢节点的待执行队列长度减小到一定长度后, Galera Cluster 数据同步又开始恢复。</p>    <p>搞清楚上面的背景原理之后,继续说明我的排障过程。</p>    <p>问题描述</p>    <p>1月29日早10点08分接收到Zabbix告警信息, 生产环境某子系统数据库集群节点1、2分别报活跃线程数超阀值,而且不断升高。</p>    <p>从业务侧尝试访问了一下该子系统,发现系统页面一直无法正常查询数据及修改数据。登陆服务器查看CPU、IO、内存情况均空闲。 说明累计的活跃线程过高,已经影响到业务的正常访问了。</p>    <p>问题分析</p>    <p>1、登陆Zabbix告警节点1、2查看数据库show global status like ‘Threads_running’情况发现Threads_running线程不断增高。</p>    <p>节点1:</p>    <p>| Threads_running|  100     |</p>    <p>节点2:</p>    <p>| Threads_running|  110     |</p>    <p>2、继续查看节点1、2数据库的show processlist的情况,发现存在很多线程停在wsrep in pre-commit stage状态(这意味着很多线程已经在节点发出commit,但将该SQL发送到其他节点是处于独立异步地进行certification test、事务插入待执行队列的状态)。这里就明了为什么会有活跃线程不断增加了,原来是线程都停留在wsrep in pre-commit stage状态。</p>    <p>3、进一步查找为什么会有线程一直停留在wsrep in pre-commit stage状态,show global status like ‘%wsrep%’,发现1、2节点接受队列并无阻塞,也没有发出流控。</p>    <p>但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端口延迟。</p>    <p>这里需要解释一下4567端口的作用(wsrep_provider_options中的gmcast.listen_addr项:主要作用是集群内监听组员状态,组员之间的通信(握手,鉴权,广播,写入集的复制)。</p>    <p>此时,问题原因已经明朗了,因为节点3与节点1、2的4567端口一直连接有延迟,所以在节点1、2执行的请求无法及时的复制给节点3执行,导致节点1、2的活跃线程一直执行不完。</p>    <p>节点1:</p>    <p>+------------------------------+-------------+</p>    <p>| Variable_name                | Value       |</p>    <p>+------------------------------+-------------+</p>    <p>| wsrep_local_recv_queue       | 0          |</p>    <p>| wsrep_local_recv_queue_avg   | 0.008711    |</p>    <p>| wsrep_flow_control_paused    | 0.000000    |</p>    <p>| wsrep_flow_control_sent      | 0          |</p>    <p>| wsrep_flow_control_recv      | 0          |</p>    <p>| wsrep_evs_delayed             | 节点3:4567 |</p>    <p>+------------------------------+-------------+</p>    <p>节点2:</p>    <p>+------------------------------+-------------+</p>    <p>| Variable_name                | Value       |</p>    <p>+------------------------------+-------------+</p>    <p>| wsrep_local_recv_queue       | 0           |</p>    <p>| wsrep_local_recv_queue_avg   | 0.006193    |</p>    <p>| wsrep_flow_control_paused    | 0.000000    |</p>    <p>| wsrep_flow_control_sent      | 0           |</p>    <p>| wsrep_flow_control_recv      | 0          |</p>    <p>| wsrep_evs_delayed             |节点3:4567 |</p>    <p>+------------------------------+-------------+</p>    <p>4、因查询数据库状态除wsrep_evs_delayed报连接延迟,其他并无异常现象,初步怀疑是网络原因造成,排查网络后,发现是因核心交换机与接入交换机之间的光模块损坏导致丢包,所以影响部分数据库集群之间的通信,才会出现以上问题。</p>    <p>在网络修复期间,因数据库集群节点3延迟丢包严重,被数据库集群仲裁后踢出了集群,剩余的节点1和节点2在运行了大约半小时后也因延迟丢包严重,出现了脑裂现象。</p>    <p>这时紧急将数据库集群3个节点关闭,然后在每个节点执行mysqld_safe --wsrep-recover命令找出最新事务号节点作为主节点启动,并在故障期间保持单节点运行。待网络故障消除后,逐一启动节点2、3,系统数据库集群恢复正常。</p>    <p>问题回顾</p>    <p>1、 在PXC环境中,如果集群各个节点的通信端口(4567)因为网络的原因出现异常(因为集群节点间通信采用的是同一网段,因此是共性的原因),应及时采取相应措施防止脑裂情况出现。例如上面故障中,因网络原因导致集群节点数从3个变为2个,这时就应该及时地关闭剩余2个节点中的一个节点,让业务只跑在单节点上,还能避免出现脑裂的情况。至少业务不会因此终断。</p>    <p>否则剩余的两个节点很快也会被网络丢包拖垮,会导致整个集群都停止服务,影响业务。当然在非多主的集群中也可以通过设置“SET GLOBAL wsrep_provider_options=’pc.ignore_sb=true’;”来取消集群判断脑裂的情况(多主环境中不建议使用)。</p>    <p>2、可以将wsrep_evs_delayed作为一个监控项进行监控,并结合网络监控进行适当的告警。</p>    <p> </p>    <p>来自:http://dbaplus.cn/news-11-1007-1.html</p>    <p> </p>