mm+keepalive简介

Posted 2021-05-01 DBA随笔

//

mm+keepalive纸上谈兵

//

    在mysql的高可用架构中，MHA、MGR等方法现在比较流行，mm+keepalive的方法目前来看是比较老旧的办法，今天对这种办法做一个简单的介绍，题目中写的"纸上谈兵"，是因为这个实验我没有做，也不打算做，旨在说明清除原理即可。

   在mm+keepalive这个方案中，先来说mm，所谓的mm就是双主复制，也可以理解是双向复制，像下面这样：

其中两个数据库的角色都是master，故称之为mm，虽然是双主，但是为了防止写入的时候产生冲突，仅在一个数据库上写，另一个数据库上读。

   这个架构带来了两个问题。

1、我们如何区分哪一个数据库是主库？

   这部分工作，其实是keepalive做的，keepaliveKeepalived是HA cluster的一种实现方案，其以vrrp协议为实现基础，在N台具有相同功能的路由器或服务器中选出一个master或多个backup，这些路由器或服务器会共用一个对外提供服务的VIP。在此HA cluster集群中，master主机会发送组播来跟backup主机进行通信确认双方是否存活。当backup主机在指定的时间内没有收到vrrp组播报文则认为master主机宕机了，此时就会在所有的backup主机中根据vrrp协议来选举出新的master主机来保证服务的高可用性。

    通过上面的过程，就实现了一个简单的MySQL的双主高可用机制。

    在来说说keepalive带来的脑裂问题：

脑裂（split-brain）：由于某些原因，导致两台keepalive高可用服务器在指定时间内，无法检测到对方的心跳消息，各自取得资源及服务的所有权，而此时的两台高可用服务器又都还活着，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。

常见原因如下：
a.服务器网线松动等网络故障
b.服务器硬件故障发生损坏现象而奔溃
c.主备服务器都开启了firewalld防火墙

   脑裂问题是在该架构中是一个比较棘手的问题，一旦发生脑裂，可能造成双主数据不一致，无法实现高可用。解决脑裂常用的办法是增加冗余的通讯线路，保证通讯线路的高可用；一旦发生脑裂现象，强行关闭其中的一个心跳节点(该操作可能需要其他软件或者服务的支持)

   改天有空的话，可以做个试验，不过现有的线上环境高可用，还是推荐使用MGR这一MySQL原生的高可用功能。

MGR相关文章：

有帮助的话还希望点下再看哈