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。