Mysql 高可用架构方案
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 模式 方案的实现方式，没有哪个方案是完美的，开发人员在选择何种方案应用到项目中也没有标准答案，合适的才是最好的。
文章转载自：一颗苹果
还未添加个人签名 2023-06-19 加入
还未添加个人简介
评论