mysql mmm和mha对比

本文简单介绍MySQL的两个high availability方案，MMM和MHA。

MMM

MMM(Master-Master replication managerfor Mysql)的基本组成如下，

主节点master1：承载写流量
备主节点master2：replicate主节点master1的写流量，在主节点故障时被monitor提升为主节点，出于与master1数据强一致的考虑，replicate模式一般配置为semi-sync
从节点slave1：replicate主节点master1的写流量，为使得master1的写足够快，一般将replicate模式设为异步
从节点salve2：类似于slave1
mmm-agent：以上3个节点都需部署的代理，与monitor进行通信
mmm-mon：即monitor，与各mmm-agent通信探测其健康情况，并决策是否要切换主节点或从节点
wvip：提供写的虚拟IP，映射到当前活跃的主节点master1
rvip：提供读的虚拟IP，至少有一个，映射到slave1或slave2

MMM的主节点切换过程如下：

master1的mmm-agent与mmm-mon长期通信失败
mmm-mon请求master1的agent，移除VIP
mmm-mon请求master2的agent，绑定VIP
mmm-mon请求slave节点的agent，连接到新master进行replicate

从节点的故障切换类似于上面的过程。

优点如下，

读写分离
fail自动切换

缺点如下，

mmm-mon存在单点故障
mmm-agent对网络抖动敏感，可能引起频繁切换
可能引起master脑裂（见下文解释）
多了一个冗余的master节点
需要比较多的VIP数量
方案基于VIP，VIP是基于ARP协议，因此所有节点必须处于同一局域网
主节点提升需要一定时间
写后即时读难以保持一致性（master同步过来的数据可能还在relay log未被应用）

MHA

MHA(Master High Availability)不同于MMM，它主要保障的是master的高可用。官方的MHA建议至少要有1主2从，淘宝TMHA则支持1主1从。其基本组成如下，

master：主节点，承载写流量
slave：从节点，replicate主节点数据，承载读流量
wvip：提供写的虚拟IP，映射到主节点
rvip：提供读的虚拟IP，如果只有一个从节点不需要
manager：与master、slave通信，负责切换主节点。注意，manager通过ssh的方式远程执行主、从节点上的脚本，需要提前将manager节点的ssh公钥放置到主、从节点；另外，manager通过mysql-client的方式去探测主、从节点的可用性，因此主、从库上也要预先为manager节点分配账户与授权

master提升主节点的流程如下，

从宕机崩溃的master保存二进制日志事件（binlog events）;
识别含有最新更新的slave；
应用差异的中继日志（relay log）到其他的slave；
应用从master保存的二进制日志事件（binlog events）；
移除旧master的VIP地址，提升一个slave为新的master；
使其他的slave连接新的master进行复制；
在新的master启动vip地址，保证前端请求可以发送到新的master

优点如下，

相比MMM不需要冗余的master节点
读写分离
自动提升主节点

缺点如下，

manager节点单点故障
可能引起master脑裂（见下文解释）
使用了VIP，同样有内网限制
主节点切换需要一定时间
写后即时读难以保持一致性
需要支持SSH私钥验证的方式登录

扩展知识：VIP与脑裂

VIP的工作原理是，

为当期主机配置一个虚拟网卡，如eth0:0，该网卡绑定了唯一的MAC地址和虚拟IP地址VIP
局域网内的主机欲与该VIP通信时，先通过ARP协议取到该VIP对应的MAC地址，再将VIP与MAC地址的对应关系缓存在其主机上
后续通信时，使用上一步骤取到的MAC作为报文的MAC地址

VIP切换的原理是，

将旧master绑定的虚拟网卡注销掉
在新的master注册新的虚拟网卡（产生了新的MAC地址）
通知局域网节点更新VIP与MAC的对应关系，后续通信采用新MAC地址

脑裂的原因，在于旧master节点没有正常将VIP摘掉，这时局域网机器通过ARP获取VIP的MAC时，就可能取到旧的MAC地址，导致与旧master通信。什么情况会出现这种情况呢？旧master由于上层交换机故障，未与manager节点正常通信，此时VIP是没有摘除掉的，过了一段时间上层交换机恢复了就会导致此问题。

参考文献