MySQL高可用架构 MMM MHA

主从架构

异步同步

在异步复制中，主库 main 不关心从库 secondary 是否接收二进制日志，因此主库 main不依赖从库 secondary 。您可以认为 main 和 secondary 是两个独立工作的服务器，数据最终将通过二进制日志保持一致。

异步复制性能最好，因为对数据库本身几乎没有开销，除非主从延迟非常大，并且转储线程需要读取大量二进制日志文件。

如果企业对数据一致性的要求较低，则可以在发生故障时容忍数据丢失。推荐异步复制，它具有最好的性能（例如微博业务，虽然它对性能要求很高，但通常可以容忍数据丢失）。而核心交易业务系统通常最关心数据安全，如监控业务和报警系统。

半同步

半同步复制分为有损和无损，有损半同步一般没有使用场景。半同步复制要求在主事务提交过程中至少有 N 个从库 secondary 接收二进制日志，这样当主库 main 停机时，至少有 N 台从库 secondary 中的数据是完整的。

1. MMM结构（双主复制的结构）

Master-Master Replication Manager for MySQL 是一套脚本集合，用以监控、管理双主复制架构，通过设置一个可写的VIP和多个只读的VIP，完成故障自动转移、读负载分摊等功能；双主互为主从

存在问题：

通过vip实现漂移，不能跨网段，更不能跨机房

网络分区，导致数据库双写，数据冲突，需要业务修改数据或者重做

DBA部署和运维不方便，容易出问题（绑定vip，配置文件等）

使用binlog进行同步会有延时，如果写节点写操作过程中挂了，集群中其他节点无法访问挂掉的 写节点的binlog，就 无法同步这部分数据，导致数据丢失。

MMM的版本已不更新，谈不上对mysql新特性的支持

不适合于对数据一致性要求很高的场景。（异步复制，数据双写冲突）

VIP地址漂移原理？

1、MMM本身的monitor和agent提供了动态变更网卡IP绑定的功能（网卡可以绑定多个IP的呢）

2、借用keepalived的虚拟路由冗余协议，实现这种高可用的VIP机制（ARP表原理）， 所以又有MM+Keepalived组合

明白了VIP地址漂移的道理，那么不能跨网段就显而易见了（多网段VIP没办法路由呢）。

2、MHA结构

MHA（Master High Availability）是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

组成部分：

1.MHA manager，管理节点

2.MHA node，数据节点

部署架构：

MHA manager可以单独部署在一台机器上，管理多个master-slave集群，也可以单独部署在一个slave节点上。MHA manager探测集群的node节点，当发现master故障时，会选取拥有最新数据的slave提升为新的master，然后将其他的slave导向新的master节点，并完成数据的同步，整个故障转移过程对于客户端应用程序来说是完全透明的。