前言：

　　Mysql是轻量化，普遍使用的关系型数据库，如此流行的部分原因是因为它很早就有了成熟的高可用方案，而数据库的HA属于运维人员必会的内容，在生产环境的应用中，不可避免的会牵扯到高可用的问题，MHA与MGR是MYSQL的两种普遍使用的高可用方案。在了解这两种方案之前，需要先了解几个Mysql高可用的常识问题：

日志Binlog与Gtid：

Binlog日志:

　　binlog是Mysql的二进制日志，记录了所有的 DDL 和 DML 语句（除了数据查询语句select、show等），以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。binlog 的主要目的是复制和恢复。在灾备或数据恢复中，一般使用binlog来对数据库进行备份来保护数据或通过执行binlog来恢复数据。binlog有三种格式：基于语句statement的复制、基于行row的复制、基于语句和行（mix）的复制。其中基于row的复制方式更能保证主从库数据的一致性，但日志量较大，在设置时考虑磁盘的空间问题。

Gtid日志：

　　GTID是MYSQL5.6新增的特性，GTID（Global Transaction Identifier）全称为全局事务标示符,用以数据库实例事务唯一标识，其组成主要是source_id和transaction_id 即GTID = source_id:transaction_id。其中source_id是数据库启动自动生成的数据库实例唯一标识，保存在auto.cnf中，而transaction_id则是事务执行的序列号。GTID是用来代替传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置。

　　总的来说Gtid的性能比mysql binlog逻辑复制好很多，因为事务的ID唯一，所以在数据恢复，数据一致性上表现较好。并且能够减少手工干预和降低服务故障时间。

高可用一般实现方式：

1、异步复制（Asynchronous replication）
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

2、全同步复制（Fully synchronous replication）
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

3、半同步复制（Semisynchronous replication）
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

4、异步与半同步异同
默认情况下MySQL的复制是异步的，Master上所有的更新操作写入Binlog之后并不确保所有的更新都被复制到Slave之上。异步操作虽然效率高，但是在Master/Slave出现问题的时候，存在很高数据不同步的风险，甚至可能丢失数据。

MySQL5.5引入半同步复制功能的目的是为了保证在master出问题的时候，至少有一台Slave的数据是完整的。在超时的情况下也可以临时转入异步复制，保障业务的正常使用，直到一台salve追赶上之后，继续切换到半同步模式。

MHA

MHA简介：

　　MHA是Master High Availability的简称，软件使用Perl语言开发，由日本DeNA公司youshimaton（现就职于Facebook公司）开发并开源，于10年发布，目前在MySQL高可用方面是一个相对成熟的解决方案。

架构：主DB2台，从DB2-N台，IP地址N+2

安装方式：在mysql服务器上安装软件包并配置。可参考：

优缺点：MHA需要自行开发VIP转移脚本，MHA只监控Master的状态，不监控Slave的状态。

MHA工作原理：

  • 从宕机崩溃的master保存二进制日志事件(binlogevents)。
  • 识别含有最新更新的slave。
  • 应用差异的中继日志(relay log)到其它slave。
  • 应用从master保存的二进制日志事件(binlogevents)。
  • 提升一个slave为新master。 -使其它的slave连接新的master进行复制。

Mha特点：

　　MHA的目的在于维持MySQL Replication中Master库的高可用性，其最大特点是可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。manager进程会定期（一般是1s一次）探测主库节点，当主库出现故障时，mha会找到应用了最新binlog日志的slave节点，并拉取主库和最新从库的差异日志并应用到该从库上。然后将该从库提升为master，并且将其他从库指向新主库，切换过程配合vip的漂移。目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有3台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库。Mha会在集群中某台slave节点安装mha manager，当master出现故障时，可以自动将已更新最新数据的slave提升为master同时将余下的slave指向新的master，整个过程是透明的，应用无感知，切换时间一般在30s以内，非常高效。Mha适用一主一从，一主多从，一般配合半同步使用，预防数据丢失。

Mgr

Mgr简介：

　　Mgr是MySQL Group Replication的简称，MYSQL官方发布的插件，C或C++开发，内置在mysql5.7.20及以后的版本中，于16年12月发布，是MySQL InnoDB Cluster高可用方案的基础。

架构：最少3节点，最多9节点，基于paxos协议复制，支持单主或多主，不同于异步复制的多Master复制集群。单主模式下，MGR集群会选出primary节点负责写请求，primary节点与其它节点都可以进行读请求处理。

安装方式：内置在mysql5.7.20及以后的版本中。执行命令即可安装。可参考：

优缺点：安装配置方便，master节点故障后，可自动完成迁移。

Mgr特点：

　　Mgr目前有两种模式，单主模式和多主模式，区别为是否提供多个节点同时写入的能力。由于mgr采用乐观锁，在高并发的情况下很容易在提交那一刻造成冲突，所以在生产环境中一般采用单主模式居多。Paxos协议能容忍少数节点宕机，因为paxos协议要求一半以上的节点收到日志主库才可以提交。在单主模式下，当主库宕机，集群会根据group_replication_member_weight设置的权重值进行备机升主，因为是强一致协议，所以不存在日志是否是最新的问题，如果权重相同，那么会根据server的uuid进行排序。mgr本身还有一些限制，比如写集合冲突问题，必须要求有主键，只支持innodb，不支持外键、save point等，还有集群的强一致导致对网络的要求较高，如果遇到网络波动，对集群的影响较大。mgr本身能够实现故障自动选举，但是生产环境需要做到对应用的透明，所以一般是基于vip的，应用连接的是vip，如果发生切换，需要将vip也漂移到新主库，这里其实还涉及到很多判断和切换逻辑，所以mgr并不是切换方案，他只是提供了一种新的强一致高可用技术，要想把它用于生产环境中其实还有很多工具和脚本要进行开发。

比较：

　　从架构上来说，Mha是外部基于mysql主从半同步开发的一套高可用切换方案，它并不属于mysql内核，独立于mysql存在于数据库外围，重点在切换，可以理解为一套切换工具。如果将Mha用在生产环境中，那么针对Mha，还需要开发一套监控及切换方案。

　　而mgr存在于mysql内核层面，是内核层面数据强一致方案，它的重点在高可用强一致，Mgr将这一整套切换方案vip之类的都考虑进去了。