MySQL高可用方案--MHA原理

简介

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就任于Facebook公司）开发，是日本的一位
MySQL专家采用Perl语言编写的一个脚本管理工具，该工具仅适用于MySQLReplication（二层）环境，目的在于维持Master主库的高可用性。是一套优秀的做为MySQL高可用性
环境下故障切换和主从提高的高可用软件。在MySQL故障切换过程当中，MHA能作到在0~30秒以内自动完成数据库的故障切换操做，而且在进行故障切换的过程当中，MHA能在最大程度上
保证数据的一致性，以达到真正意义上的高可用。

MHA是自动的master故障转移和Slave提高的软件包.它是基于标准的MySQL复制(异步/半同步).该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。
1）MHA Manager能够单独部署在一台独立的机器上管理多个master-slave集群，也能够部署在一台slave节点上。MHA Manager会定时探测集群中的node节点,当发现master
出现故障的时候,它能够自动将具备最新数据的slave提高为新的master,而后将全部其它的slave导向新的master上.整个故障转移过程对应用程序是透明的。
2）MHA Node运行在每台MySQL服务器上，它经过监控具有解析和清理logs功能的脚原本加快故障转移的。

在MHA自动故障切换过程当中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不老是可行的。例如，若是主服务器硬件故障或没法经过ssh访问，
MHA无法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5或者之后的版本的半同步复制，能够大大下降数据丢失的风险。MHA能够与半同步复制结合起来。若是只有一个slave
已经收到了最新的二进制日志，MHA能够将最新的二进制日志应用于其余全部的slave服务器上，所以能够保证全部节点的数据一致性。

目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另一台充当从库，由于至
少须要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。

工做架构

展现了如何经过MHA Manager管理多组主从复制。能够将MHA工做原理总结为以下：

具体的工做流程以下:

相较于其它HA软件，MHA的目的在于维持MySQL Replication中Master库的高可用性，其最大特色是能够修复多个Slave之间的差别日志，最终使全部Slave保持数据一致，
而后从中选择一个充当新的Master，并将其它Slave指向它。工做流程主要以下：
1）从宕机崩溃的master保存二进制日志事件（binlog events）;
2）识别含有最新更新的slave；
3）应用差别的中继日志（relay log）到其余的slave；
4）应用从master保存的二进制日志事件（binlog events）；
5）提高一个slave为新的master；
6）使其余的slave链接新的master进行复制；

工做原理

 

当master出现故障时，经过对比slave之间I/O线程读取master binlog的位置，选取最接近的slave作为latest slave。其它slave经过与latest slave对比生成差别中继日志。
在latest slave上应用从master保存的binlog，同时将latest slave提高为master。最后在其它slave上应用相应的差别中继日志并开始重新的master开始复制。

在MHA实现Master故障切换过程当中，MHA Node会试图访问故障的master（经过SSH），若是能够访问（不是硬件故障，好比InnoDB数据文件损坏等），会保存二进制文件，以最大程度
保证数据不丢失。MHA和半同步复制一块儿使用会大大下降数据丢失的危险。

优点

1）故障切换快
在主从复制集群中，只要从库在复制上没有延迟，MHA一般能够在数秒内实现故障切换。9-10秒内检查到master故障，能够选择在7-10秒关闭master以免出现裂脑，几秒钟内，
将差别中继日志（relay log）应用到新的master上，所以总的宕机时间一般为10-30秒。恢复新的master后，MHA并行的恢复其他的slave。即便在有数万台slave，也不会
影响master的恢复时间。

DeNA在超过150个MySQL（主要5.0/5.1版本）主从环境下使用了MHA。当mater故障后，MHA在4秒内就完成了故障切换。在传统的主动/被动集群解决方案中，4秒内完成故障切换是不可能的。

2）master故障不会致使数据不一致
当目前的master出现故障时，MHA自动识别slave之间中继日志（relay log）的不一样，并应用到全部的slave中。这样全部的salve可以保持同步，只要全部的slave处于存活
状态。和Semi-Synchronous Replication一块儿使用，（几乎）能够保证没有数据丢失。

3）无需修改当前的MySQL设置
MHA的设计的重要原则之一就是尽量地简单易用。MHA工做在传统的MySQL版本5.0和以后版本的主从复制环境中。和其它高可用解决方法比，MHA并不须要改变MySQL的部署环境。
MHA适用于异步和半同步的主从复制。

启动/中止/升级/降级/安装/卸载MHA不须要改变（包扩启动/中止）MySQL复制。当须要升级MHA到新的版本，不须要中止MySQL，仅仅替换到新版本的MHA，而后重启MHA　Manager
就行了。

MHA运行在MySQL 5.0开始的原生版本上。一些其它的MySQL高可用解决方案须要特定的版本（好比MySQL集群、带全局事务ID的MySQL等等），但并不只仅为了master的高可用才迁移应用的。在大多数状况下，已经部署了比较旧MySQL应用，而且不想仅仅为了实现Master的高可用，花太多的时间迁移到不一样的存储引擎或更新的前沿发行版。MHA工做的包括5.0/5.1/5.5的原生版本的MySQL上，因此并不须要迁移。

4）无需增长大量的服务器
MHA由MHA Manager和MHA Node组成。MHA Node运行在须要故障切换/恢复的MySQL服务器上，所以并不须要额外增长服务器。MHA Manager运行在特定的服务器上，所以须要
增长一台（实现高可用须要2台），可是MHA Manager能够监控大量（甚至上百台）单独的master，所以，并不须要增长大量的服务器。即便在一台slave上运行MHA Manager也是
能够的。综上，实现MHA并没用额外增长大量的服务。

5）无性能降低
MHA适用与异步或半同步的MySQL复制。监控master时，MHA仅仅是每隔几秒（默认是3秒）发送一个ping包，并不发送重查询。能够获得像原生MySQL复制同样快的性能。

6）适用于任何存储引擎
MHA能够运行在只要MySQL复制运行的存储引擎上，并不只限制于InnoDB，即便在不易迁移的传统的MyISAM引擎环境，同样可使用MHA。

软件架构

MHA软件的架构：由两部分组成，Manager工具包和Node工具包
Manager工具包主要包括如下几个工具：
masterha_check_ssh      检查MHA的SSH配置状态
masterha_check_repl     检查MySQL复制的状态
masterha_check_status   检查MHA当前的运行状态
masterha_manger         启动MHA
masterha_master_monitor 检测master是否宕机
masterha_master_switch  控制故障转移(手动或者自动)
masterha_conf_host      添加或者删除配置的server信息

Node工具包（这些工具一般由MHA Manager的脚本触发，无需人为操做）主要包括如下几个工具：
save_binary_logs        保存和复制master的二进制日志
apply_diff_relay_logs   识别差别的中继日志事件并将其差别的事件应用于其余的slave服务器
filter_mysqlbinlog      去除没必要要的ROLLBACK事件(MHA已经不在使用这个工具了)
purge_relay_logs        清除中继日志(不会阻塞SQL线程)

MHA如何保持数据的一致性呢？主要经过MHA node的如下几个工具实现，可是这些工具由mha manager触发：
save_binary_logs        若是master的二进制日志能够存取的话，保存复制master的二进制日志，最大程度保证数据不丢失
apply_diff_relay_logs   相对于最新的slave，生成差别的中继日志并将全部差别事件应用到其余全部的slave

注意：
对比的是relay log，relay log越新就越接近于master，才能保证数据是最新的。
purge_relay_logs        删除中继日志而不阻塞sql线程

MHA环境部署

更加精彩部署篇点击连接：http://www.javashuo.com/article/p-woqonius-k.html