MHA vs MGR谁更合适用在生产系统

MySQL为什么如此流行的原因是因为它很早就有了非常成熟的高可用方案，这个方案就是mha，很多互联网公司都是基于mha做的高可用，所有受众面非常广。其实还有个小原因就是我们从上大学学习数据库原理这门课的时候老师就是拿mysql数据库作为例子，使得我们大部分人对它更加熟悉。

相比起来pg的流复制出来的较晚，而且高可用方案也不统一，虽然流复制是基于xlog物理日志的复制技术，性能比mysql binlog逻辑复制好很多，但是相比起来pg差在生态上，在中国pg的客群并不大，受众面没那么广。

好，进入正题，mysql的mha和mgr到底谁才是“正房”。谁才是生产环境中最好的高可用方案。

这么比较其实是有点问题的。我们知道mha是外部的基于mysql主从半同步开发的一套高可用切换方案，它并不属于mysql内核，独立于mysql存在于外围，mha重点在切换，可以理解为一套切换工具。而mgr存在于mysql内核层面，是内核层面数据强一致方案，它的重点在高可用强一致，如果将mgr用在生产环境中，那么针对mgr，还需要开发一套监控及切换方案，而mha将这一整套切换方案vip之类的都考虑进去了。

mha会在集群中某台机器一般是slave节点安装mha manager，当master出现故障时，可以自动将最新数据的slave提升为master同时将所有其他的slave指向新的master，整个过程是透明的，对应用无感知，切换时间一般在30s以内，非常高效。mha适用于一主一从，一主多从，一般配合半同步使用，预防数据丢失。

mha大致原理是manager进程会定期（一般是1s一次）探测主库节点，当主库出现故障时，mha会找到应用了最新日志的slave的binlog位置，并且拉取主库和最新从库的差异日志并应用到该从库上。，然后将该从库提升为master，并且将其他从库指向新主库，切换过程配合vip的漂移。

mgr全称是mysql group replication，它其实是对mysql半同步的一个创新，它至少要求三个节点，三个节点间基于paxos协议做同步，paxos协议是多主节点的强一致协议。

mgr有两种模式，单主模式和多主模式，区别就是是否提供多个节点同时写入的能力。由于mgr采用乐观锁，在高并发的情况下很容易在提交那一刻造成冲突，所以在生产环境中一般采用单主模式居多。

Paxos协议能容忍少数节点宕机，因为paxos协议要求一半以上的节点收到日志主库才可以提交。在单主模式下，当主库宕机，集群会根据group_replication_member_weight设置的权重值进行备机升主，因为是强一致协议，所以不存在日志是否是最新的问题，如果权重相同，那么会根据server的uuid进行排序。

mgr本身还有一些限制，比如写集合冲突问题，必须要求有主键，只支持innodb，不支持外键、save point等，还有集群的强一致导致对网络的要求较高，如果遇到网络波动，对集群的影响较大。

mgr本身能够实现故障自动选举，但是生产环境需要做到对应用的透明，所以一般是基于vip的，应用连接的是vip，如果发生切换，需要将vip也漂移到新主库，这里其实还涉及到很多判断和切换逻辑，所以mgr并不是切换方案，他只是提供了一种新的强一致高可用技术，要想把它用于生产环境中其实还有很多工具和脚本要进行开发。

个人觉得，mha在mysql的高可用方面还是最经典成熟和无可撼动的。至于mgr新技术大家也可以抱着研究的心态玩一玩，但是说用mgr来替换mha不管从成本还是可靠性考虑我觉得都不可取，仅代表个人观点哈。

好吧，加油吧。