mm+keepalive简介

//

mm+keepalive纸上谈兵

//

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

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

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

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

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

2、一旦主库宕机，如何让服务的IP地址连接到另外一个库上？

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

简单来说，keepalive就是选举当前写节点的一个服务，入股写节点宕机，那么keepalive会将另外一个节点选作主节点。在这个过程中，需要一个额外的VIP地址(virtual IP,虚拟IP地址)。架构图如下：

假设左侧master IP地址为:192.168.1.100

右侧slave IP地址为：192.168.1.101

VIP的地址为：192.168.1.200

正常情况下，应用服务是直接连接192.168.1.200的，这个VIP地址绑定在了192.168.1.100这台机器上，keepalive通过心跳的机制来检测当前谁是这个MySQL系统的写节点，当这台机器宕机的时候，keepalive服务会让VIP做一个漂移的动作，漂移到192.168.1.101上,这样就完成了切换，对于上层应用服务来讲，该过程是无法感知的。

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

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

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

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

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

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