Mysql 介绍

Mysql 是典型的开源关系型数据库，是许多网站、应用程序、企业软件产品的首选数据库。

Mysql 特性：

• 易于使用，功能强大，支持事务、触发器、存储过程

• 管理工具多种多样且功能丰富

• 可以作为千万级数据管理的大型数据库

• 采用 GPL 开源协议，允许自由修改源码并应用到商业系统中

• Mysql 的 InnoDB 事务性存储引擎符合事务 ACID 模型，能保证完整、可靠地进行数据地存储

高可用结构

• 主从模式

• MHA

• MMM

• MGR

主从模式

主从模式介绍

主从模式是最基本的 Mysql 高可用架构，一台服务器作为 Master 节点，若干服务器作为 Slave 节点。只有 Master 处理写数据请求，读请求可仅由 Slave 节点处理，也可让 Master、Slave 同时处理。

Master 和 Slave 通过主从复制技术保持数据一致，即 Master 节点将数据同步给 Slave 节点。

主从模式具备高可用的基础是主从复制技术。

主从复制技术

• 当 Master 数据发生变更（新增、删除、修改）时，Master 将变更日志写入二进制日志文件 binlog

• Slave 启动单独线程（I/O 线程）与 Master 建立网络连接，从 Master 的 binlog 中获取变更日志

• Slave 的 I/O 线程捕获到数据变更日志后，按照顺序保存到中继日志文件 relay log

• Slave 启动单独线程（Sql 线程）从 relay log 中读取日志并执行，使 Slave 库的数据和 Master 一致

主从模式注意事项

Mysql 5.5 之前主从复制为异步方式，Master 提交事务不需要经过 Slave 们的确认，那么就会有这种极端情况：

• Slave 读取 Master 的 binlog 失败了

• Slave 处理 relay log 失败了

• Slave 执行 Sql 语句失败了

• 等......

类似的极端情况将导致数据不一致。所以在 Mysql 5.5 主从复制提供了半同步的方式，具体来说就是增加了 ACK 确认的机制，当 Slave 接收到 binlog 后，会给 Master 发送一条确认消息，Master 在接收到 ACK 确认消息之后才会提交事务。半同步方式可以提高数据的一致性，但是 Master 在写入数据的时候需要等待 Slave 的确认，所以性能会有所下降。

复制风暴问题，来考虑这样一种更加极端的情况，一个 Master ，10 个 Slave ， 这种情况下基于主从复制技术，Master 在写入数据前需要同时处理 10 个 Slave 的数据复制请求，这种情况下对于 Master 只能说是不堪重负，如果在加上“半同步机制”，写入性能将大打折扣，这种情况称之为复制风暴问题。解决这种问题的方法是，Master 仅处理一个 Slave 的主从复制，其它的 Slave 复制由 Slave 负责。

MHA（MasterHighAvailability）

MHA 模式介绍

以主从模式为基础，接下来就该考虑如下问题了：

• 如何检测节点故障

• master 节点故障之后如何重新选举

MHA 就是在解决这两个问题的，理论上，MHA 模式可以在 10s-30s 内完成主从集群的自动故障检测和自动主从切换。

MHA 由两个部分组成：

• MHA-Manager：负责自动检测 Master 是否故障，检查主从复制状态，执行自动主从切换等。需要单独服务器部署。

• MHA-Node：负责修复主从数据的差异，通常和 Mysql 服务器实例绑定部署。

MHA 工作流程

• Manager 和 Master 之间心跳，如果连续 4 次探测不到心跳，就认为该 Master 宕机了，Master 实例绑定一个 Node。

• Manager 分析各个 Slave 的 binlog，选择一个更接近 Master 数据的 Slave 作为备选 Master，一个 Slave 实例分别绑定一个 Node。

• Slave 的 Node 试图通过 SSH 访问 Master 所在服务器：

  如果可达，Slave 的 Node 获取 Master 的 binlog 数据，若发现 Master 和 Slave 数据存在差异，会将差异数据主动复制到 Slave，以保持主从数据一致。

  如果不可达，Node 对比各个 Slave 的 relay log 差异，并做差异数据补齐。

• Manager 将备选 Master 提升为 Master。

MMM（Multi-MasterReplicationManagerForMysql）

MMM 模式简单来说就是引入虚拟 IP（vip）技术，这种架构下，一个集群中有两个 Master 和若干个 Slave，当其中一个 Master 不可用的时候，MMM 会指示 vip 切换到另外一个 Master 上面，同时会向所有的 Slave 发送更换 Master 的消息，之后主从复制将切换到新的 Master。

此方案比较古老，不支持 Mysql GTID ，并且社区活跃度不够，目前处于无人维护的状态。

MGR（MysqlGroupReplication）

MGR，Mysql 组复制模式是 Mysql5.7.17 版本推出的高可用解决方案，具备如下特性：

• 一致性高：数据复制基于分布式共识算法 Paxos，可以保证多个节点数据的一致性

• 容错性高：只要不是超过一半的节点宕机，就可以继续提供服务

• 灵活性强：MGR 支持单主模式和多主模式，单主模式下如果 Master 故障，Slave 们会重新选举一个新的 Master，多主模式下每一个 Mysql 节点都可以同时处理写请求

MGR 要求至少由 3 个 Mysql 节点组成一个复制组，即一主两从，一个事务必须经过复制组内超过半数节点通过后才能提交。

如果在不同的 Mysql 节点上执行不同的写操作发生了事务冲突，那么先提交的事务先执行，后提交的事务被回滚。在多主模式下，由于每个 Mysql 节点都可以执行写请求，在写请求高并发的场景下发生事务冲突的概率会非常大，会造成大量事务回滚。

在单主模式下，MGR 会自动为复制组选择一个 Master 负责写请求，如果复制组内超过一半节点与 Master 通信失败，就认为 Master 宕机了，这时会根据各个节点的权重和 ID 标识重新选主。

MGR 更加适合一致性强，写并发量不大的场景下使用。

总结

本文阐述了 Mysql 高可用架构方案，介绍了 主从模式，MHA 模式，MMM 模式，MGR 模式 方案的实现方式，没有哪个方案是完美的，开发人员在选择何种方案应用到项目中也没有标准答案，合适的才是最好的。

本文作者： 一颗苹果

本文链接： https://www.cnblogs.com/Naylor/p/18539381