MySQL第七讲 MySQL的高可用方案_mysql高可用方案

 MMM

      

优点：

1:提供了读写VIP的配置，使读写请求都可以达到高可用

2:工具包相对比较完善，不需要额外的开发脚本

3:完成故障转移之后可以对MySQL集群进行高可用监控

 缺点：

1:故障简单粗暴，容易丢失事务，建议采用半同步复制方式，减少失败的概率

2:目前MMM社区已经缺少维护，不支持基于GTID的复制

适用场景：

1:读写都需要高可用的

2:基于日志点的复制方式

MHA 

        MHA是需要单独部署的，分为Manager节点和Node节点，两种节点。其中 Manager节点一般是单独部署的一台机器。而Node节点一般是部署在每台MySQL 机器上的。 Node节点得通过解析各个MySQL的日志来进行一些操作。 Manager节点会通过探测集群里的Node节点去判断各个Node所在机器上的 MySQL运行是否正常，如果发现某个Master故障了，就直接把他的一个Slave提升 为Master，然后让其他Slave都挂到新的Master上去，完全透明。

        目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器。

 优点：

1:MHA除了支持日志点的复制还支持GTID的方式

2:同MMM相比，MHA会尝试从旧的Master中恢复旧的二进制日志，只是未必每 次都能成功。如果希望更少的数据丢失场景，建议使用MHA架构。

缺点：

1:MHA需要自行开发VIP转移脚本。

2:MHA只监控Master的状态，未监控Slave的状态

 MGR

支持多主模式，但官方推荐单主模式：

多主模式下，客户端可以随机向MySQL节点写入数据

单主模式下，MGR集群会选出primary节点负责写请求，primary节点与其它节 点都可以进行读请求处理

 优点：

基本无延迟，延迟比异步的小很多

支持多写模式，但是目前还不是很成熟

数据的强一致性，可以保证数据事务不丢失

缺点:

仅支持innodb，且每个表必须提供主键。

只能用在GTID模式下，且日志格式为row格式。

适用的业务场景：

1:对主从延迟比较敏感

2:希望对对写服务提供高可用，又不想安装第三方软件

3:数据强一致的场景