Mysql是典型的开源关系型数据库，是许多网站、应用程序、企业软件产品的首选数据库。
Mysql特性：
主从模式
MHA
MMM
MGR
主从模式是最基本的Mysql高可用架构，一台服务器作为Master节点，若干服务器作为Slave节点。只有Master处理写数据请求，读请求可仅由Slave节点处理，也可让Master、Slave同时处理。
Master和Slave通过主从复制技术保持数据一致，即Master节点将数据同步给Slave节点。
主从模式具备高可用的基础是主从复制技术。
Mysql 5.5之前主从复制为异步方式，Master 提交事务不需要经过Slave 们的确认，那么就会有这种极端情况：
类似的极端情况将导致数据不一致。所以在Mysql 5.5 主从复制提供了半同步的方式，具体来说就是增加了ACK确认的机制，当Slave接收到binlog 后，会给Master 发送一条确认消息，Master在接收到ACK确认消息之后才会提交事务。半同步方式可以提高数据的一致性，但是Master在写入数据的时候需要等待Slave的确认，所以性能会有所下降。
复制风暴问题，来考虑这样一种更加极端的情况，一个Master ，10个Slave ， 这种情况下基于主从复制技术，Master在写入数据前需要同时处理10个Slave的数据复制请求，这种情况下对于Master只能说是不堪重负，如果在加上“半同步机制”，写入性能将大打折扣，这种情况称之为复制风暴问题。解决这种问题的方法是，Master 仅处理一个Slave的主从复制，其它的Slave复制由Slave负责。
以主从模式为基础，接下来就该考虑如下问题了：
MHA就是在解决这两个问题的，理论上，MHA模式可以在10s-30s内完成主从集群的自动故障检测和自动主从切换。
MHA由两个部分组成：
Manager 和 Master之间心跳，如果连续4次探测不到心跳，就认为该Master宕机了，Master实例绑定一个Node。
Manager 分析各个Slave的binlog，选择一个更接近Master数据的Slave作为备选Master，一个Slave实例分别绑定一个Node。
Slave的Node试图通过SSH访问Master所在服务器：
Manager将备选Master提升为Master。
MMM模式简单来说就是引入虚拟IP（vip）技术，这种架构下，一个集群中有两个Master和若干个Slave，当其中一个Master不可用的时候，MMM会指示vip切换到另外一个Master上面，同时会向所有的Slave发送更换Master的消息，之后主从复制将切换到新的Master。
此方案比较古老，不支持Mysql GTID ，并且社区活跃度不够，目前处于无人维护的状态。
MGR，Mysql组复制模式是Mysql5.7.17版本推出的高可用解决方案，具备如下特性：
MGR要求至少由3个Mysql节点组成一个复制组，即一主两从，一个事务必须经过复制组内超过半数节点通过后才能提交。
如果在不同的Mysql节点上执行不同的写操作发生了事务冲突，那么先提交的事务先执行，后提交的事务被回滚。在多主模式下，由于每个Mysql节点都可以执行写请求，在写请求高并发的场景下发生事务冲突的概率会非常大，会造成大量事务回滚。
在单主模式下，MGR会自动为复制组选择一个Master负责写请求，如果复制组内超过一半节点与Master通信失败，就认为Master宕机了，这时会根据各个节点的权重和ID标识重新选主。
MGR更加适合一致性强，写并发量不大的场景下使用。
本文阐述了Mysql高可用架构方案，介绍了 主从模式，MHA模式，MMM模式，MGR模式 方案的实现方式，没有哪个方案是完美的，开发人员在选择何种方案应用到项目中也没有标准答案，合适的才是最好的。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。