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是没有摘除掉的,过了一段时间上层交换机恢复了就会导致此问题。
参考文献
- MySQL High Availability at GitHub - The GitHub Blog
- https://dzone.com/articles/choosing-mysql-high-availability-solutions
- 美团点评MySQL数据库高可用架构从MMM到MHA+Zebra以及MHA+Proxy的演进-腾讯云开发者社区-腾讯云
- mysql复制高可用方案总结 – 西门飞冰的博客