概述

由于MHA内容比较多，所以这里先介绍概念篇，后面再介绍实战篇。先理论，再实践。

一、简介

　　 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在10~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

　　MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中 (通过将从库提升为主库)，大概0.5-2秒内即可完成。

　　该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

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

MHA 0.56 开始，就可以支持GTID了，GTID 天生就是为了HA而产生的。 MHA + GTID 可以非常好的解决HA的问题，GTID支持多层级的复制故障转移，MHA不行。

二、MHA 服务角色

　　MHA 服务有两种角色， MHA Manager(管理节点)和 MHA Node(数据节点)：

1)MHA Manager：

　　通常单独部署在一台独立机器上管理多个 master/slave 集群(组)，每个 master/slave 集群称作一个 application，用来管理统筹整个集群。

2)MHA node：

　　运行在每台 MySQL 服务器上(master/slave/manager)，它通过监控具备解析和清理 logs 功能的脚本来加快故障转移。

　　主要是接收管理节点所发出指令的代理，代理需要运行在每一个 mysql 节点上。简单讲 node 就是用来收集从节点服务器上所生成的 bin-log 。对比打算提升为新的主节点之上的从节点的是否拥有并完成操作，如果没有发给新主节点在本地应用后提升为主节点。

　　由上图我们可以看出，每个复制组内部和 Manager 之间都需要ssh实现无密码互连，只有这样，在 Master 出故障时， Manager 才能顺利的连接进去，实现主从切换功能。

三、MHA提供的工具

　　MHA会提供诸多工具程序， 其常见的如下所示：

1)Manager节点：

　　masterha_check_ssh：MHA 依赖的 ssh 环境监测工具；

　　masterha_check_repl：MYSQL 复制环境检测工具；

　　masterga_manager：MHA 服务主程序；

　　masterha_check_status：MHA 运行状态探测工具；

　　masterha_master_monitor：MYSQL master 节点可用性监测工具；

　　masterha_master_swith:master：节点切换工具；

　　masterha_conf_host：添加或删除配置的节点；

　　masterha_stop：关闭 MHA 服务的工具。

2)Node节点：（这些工具通常由MHA Manager的脚本触发，无需人为操作）

　　save_binary_logs：保存和复制 master 的二进制日志；

　　apply_diff_relay_logs：识别差异的中继日志事件并应用于其他 slave；

　　purge_relay_logs：清除中继日志（不会阻塞 SQL 线程）；

　　自定义扩展：

　　secondary_check_script：通过多条网络路由检测master的可用性；

　　master_ip_failover_script：更新application使用的masterip；

　　report_script：发送报告;

　　init_conf_load_script：加载初始配置参数；

　　master_ip_online_change_script;更新master节点ip地址。

四、工作原理

MHA工作原理总结为以下几条：

（1） 从宕机崩溃的 master 保存二进制日志事件（binlog events）；

（2） 识别含有最新更新的 slave ；

（3） 应用差异的中继日志(relay log) 到其他 slave ；

（4） 应用从 master 保存的二进制日志事件(binlog events)；

（5） 提升一个 slave 为新 master ；

（6） 使用其他的 slave 连接新的 master 进行复制。

五、MHA优点总结

1）Masterfailover and slave promotion can be done very quickly

自动故障转移快

2）Mastercrash does not result in data inconsistency

主库崩溃不存在数据一致性问题

3）Noneed to modify current MySQL settings (MHA works with regular MySQL)

不需要对当前mysql环境做重大修改

4）Noneed to increase lots of servers

不需要添加额外的服务器(仅一台manager就可管理上百个replication)

5）Noperformance penalty

性能优秀，可工作在半同步复制和异步复制，当监控mysql状态时，仅需要每隔N秒向master发送ping包(默认3秒)，所以对性能无影响。你可以理解为MHA的性能和简单的主从复制框架性能一样。

6）Works with any storage engine

只要replication支持的存储引擎，MHA都支持，不会局限于innodb

后面会分享更多devops和DBA方面内容，感兴趣的朋友可以关注下！