一、MMM和MHA架构的作用
1、对主从复制集群中的master进行健康监控
2、当master宕机后，把写VIp迁移到新的master
3、重新配置集群中的其他slave对新的master的同步
二、MMM架构
1、概述
MMM架构中，有一个专门的监控服务器安装mmm_monitor组装，配合安装在各个实例节点的mmm_agent组件，来监控各个实例的健康状况。
MMM架构中，有两个主，但只有一个主提供服务，它们之间互为主备，互相同步数据。
MMM架构中，对外提供的访问IP分为写VIP和读VIP。写服务访问写VIP，读服务访问读VIP中的一个。
当主挂掉之后，主和主备之间的同步也会中断，MMM工具会把原来挂在主服务器的多个salve迁移到主备上面，并且把写VIP也迁移到主备服务器上。
当某个从挂掉之后，比如从-1宕机，MMM管理工具会根据slave的负载情况，把原来绑定在从-1的读VIP-1迁移到其他的从服务器上，比如迁移到读VIp-3。这时，实际上，在从-3服务器上，就绑定了两个读VIP。
2、组成MMM架构需要的资源
| 资源 | 数量 | 说明 |
|---|---|---|
| 主DB | 2 | 用于主备模式的主主复制的配置 |
| 从DB | 0-N | 可以配置0到多台从服务器 |
| IP地址 | 2N+1 | 每个实例有一个物理IP和一个虚拟IP，再加上一个监控工具使用的IP |
| 监控用户 | 1 | 用于监控数据库状态的MySQL用户（拥有replication client权限） |
| 代理用户 | 1 | 用于MMM的agent端用于改变read_only状态（拥有super、replication client、process权限） |
| 复制用户 | 1 | 用于配置MySQL复制的MySQL用户（拥有replication slave权限） |
3、配置MMM架构的步骤
（1）配置主主复制的集群架构
（2）安装yum扩展源
（3）安装所需的perl支持包
（4）安装MMM工具包
（5）配置并启用MMM服务
4、MMM架构的优缺点
（1）优点：
提供了读写VIP的配置，使读写请求都可以达到高可用
工具包相对完善，不需要额外开发脚本
完成故障转移后，可以持续对MySQL集群进行高可用监控
（2）缺点
（2.1）故障切换简单粗暴易丢事务
在MMM架构中，有两个主，互为主备，主下面又挂了多个从，但当主挂掉后，并不能保证主备一定是事务完全同步的，也并不能保证主备相对于从来说，数据完整性是最接近于主的。
这点可以通过在主备之间采用5.7版本以后开始支持的半同步复制来解决，使得主备的数据相对于从的数据来说，是最接近与主的。
（2.2）不支持基于GTID的复制方式
目前MMM社区已经缺少了必要的维护，因此对于新推出的基于GTID的复制方式，MMM
架构是不支持的
要解决该问题，只能执行修改MMM管理工具中的perl脚本来实现。
（2.3）社区并不活跃，很久未更新版本
5、MMM架构的适用场景
（1）使用基于日志点复制的主从复制方式
（2）当前正在使用主主复制的架构，可以考虑使用MMM管理工具来进行管理
（3）需要考虑读高可用的场景
MMM架构同时提供了读VIP和写VIP，而MHA架构则只提供了写VIP，也就是说在MHA中，并不会对slave的宕机进行监控。
三、MHA架构
1、概述
在监控服务器上，需要安装mha_manage和mha_node组件，在被监控的服务器上需要安装mha_node组件。
当master挂掉后，mha工具会从当前多个slave中找到数据同步最接近master的slave，将其提升为master，将写VIP迁移到新的master，并配置其他slave对新的master进行数据同步。
2、组成MHA架构需要的资源
| 资源 | 数量 | 说明 |
|---|---|---|
| 主DB | 1 | 用于初始主从复制的master服务器 |
| 从DB | 2~N | 可以配置2到N台slave服务器 |
| 监控服务 | 1 | 用于监控 |
| IP地址 | N+2 | N为MySQL服务器实例的数量， 另外两个分别用于写VIP和监控服务 |
| 监控用户 | 1 | 用于监控数据库状态的MySQL用户（all privileges） |
| 复制用户 | 1 | 用于配置MySQL复制的MySQL用户（replication slave） |
3、配置MHA架构的步骤
（1）配置一主多从的复制架构
（2）安装centos的yum扩展源及依赖包
（3）配置集群内各主机的ssh免认证
（4）在各节点安装mha_node软件
（5）在管理节点安装mha_manager
（6）配置并启动MHA管理进程
4、MHA架构的优点
（1）支持基于GTID的复制和基于日志点的复制方式
相比于MMM架构工具只支持基于日志点的复制方式，MHA添加了对基于GTID的复制方式的支持
（2）可以从多个slave中选举最合适的新master
（3）会尝试从旧的master中尽可能多的保存未同步日志
这一步可以保证在master宕机后，可以尽可能少的丢失事务。相比于MMM架构，MHA在这点上是MMM没有做到的。
4、MHA架构的缺点
（1）未必一定能获取到旧主未同步的日志
可以使用5.7版本以后开始支持的半同步复制来解决，通过半同步复制，可以很大程度的保证slave接收到master全部的二进制日志，这样就可以大幅度降低事务丢失的风险。
但与此同时，采用半同步复制虽然可以很大程度的降低事务丢失的风险，但也在一定程度上降低了事务写性能，因此需要进行一定的取舍。
（2）需要自行开发写VIP迁移脚本
虽然MHA提供了脚本模板，但要保证整个脚本都能正常运行，还需要我们具备一定的开发能力。
（3）只监控master，而没有对slave实现高可用
因为mha并没有对slave的监控，因此我们需要采用额外的方式来对slave进行监控
5、MHA适用场景
（1）使用基于GTID的主从复制方式
因为MMM架构只支持基于日志点复制的方式，因此如果我们的主从复制采用的是基于GTID的复制，那我们就只能选择MHA架构
（2）使用一主多从的复制架构
因为MMM架构必须要有两个主互为主备，下面再挂上多个slave，因此如果我们使用的是一主多从的架构，因为只有一主，就搭建不了MMM架构，这时也只能选择MHA架构
（3）希望更少的数据丢失的场景