MHA 功能及介绍

概述

MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案，来保证 数据库系统的高可用.在宕机的时间内（通常10—30秒内），完成故障切换，部署MHA，可避免主从一致性问题，节约购买新服务器的费用，不影响服务器性能，易安装，不改变现有部署。

还支持在线切换，从当前运行master切换到一个新的master上面，只需要很短的时间（0.5-2秒内），此时仅仅阻塞写操作，并不影响读操作，便于主机硬件维护。

在有高可用，数据一致性要求的系统上，MHA 提供了有用的功能，几乎无间断的满足维护需要。

优点

1 master自动监控和故障转移( 红色4点功能)

在当前已存在的主从复制环境中，MHA可以 1 监控master主机故障，并且 4 故障自动转移。

即使有一些slave没有接受新的relay log events，2MHA也会从最新的slave自动识别差异的relay log events，3并apply差异的event到其他slaves。因此所有的slave都是一致的。MHA秒级别故障转移（9-12秒监测到主机故障，任选7秒钟关闭电源主机避免脑裂，接下来apply差异relay logs，注册到新的master，通常需要时间10-30秒即total downtime）。另外，在配置文件里可以配置一个slave优先成为master。因为MHA修复了slave之间的一致性，dba就不用去处理一致性问题。

当迁移新的master之后，并行恢复其他slave。即使有成千上万的slave,也不会影响恢复master时间，slave也很快完成。

DeNA公司在150+主从环境中用MHA。当其中一个master崩溃，MHA4秒完成故障转移，这是主动/被动集群解决方案无法完成的。

2 互动(手动)master故障转移

MHA可以用来只做故障转移，而不监测master，MHA只作为故障转移的交互。

3 非交互式故障转移

非交互式的故障转移也提供（不监控master，自动故障转移）。这个特性很有用，特别是你已经安装了其他软件监控master。比如，用Pacemaker(Heartbeat)监测master故障和vip接管，用MHA故障转移和slave提升。

4 在线切换master到不同主机

在很多情况下，有必要将master转移到其他主机上（如替换raid控制器，提升master机器硬件等等）。这并不是master崩溃，但是计划维护必须去做。计划维护导致downtime，必须尽可能快的恢复。快速的master切换和优雅的阻塞写操作是必需的，MHA提供了这种方式。优雅的master切换， 0.5-2秒内阻塞写操作。在很多情况下0.5-2秒的downtime是可以接受的，并且即使不在计划维护窗口。这意味着当需要更换更快机器，升级高版本时，dba可以很容易采取动作。

5 master crash不会导致主从数据不一致性

当master crash后，MHA自动识别slave间relay logevents的不同，然后应用与不同的slave，最终所有slave都同步。结合通过半同步一起使用，几乎没有任何数据丢失。

其他高可用方案

6 MHA部署不影响当前环境设置

MHA最重要的一个设计理念就是尽可能使用简单。 使用于5.0+以上主从环境，其他HA方案需要改变 mysql部署设置，MHA不会让dba做这些部署配置，同步和半同步环境都可以用。启动/停止/升级/降级/安装/卸载 MHA都不用改变mysql主从（如启动/停止）。

当你需要升级MHA到新版本时，不需要停止mysql，仅仅更新HMA版本，然后重新启动MHAmanger即可。

MHA 支持包含5.0/5/1/5.5(应该也支持5.6，翻译文档时MHA开发者没更新对于5.6版本)。有些HA方案要求特定的mysql版本（如mysqlcluster，mysql with global transaction id 等）,而且你可能不想仅仅为了MasterHA而迁移应用。很多情况下，公司已经部署了许多传统的mysql应用，开发或dba不想花太多时间迁移到不同的存储引擎或新的特性（newer bleeding edge distributions 不知道这个是否该这么翻译）。

7 不增加服务器费用

MHA 包含MHA Manager和MHA node。MHA node运行在每台mysql服务器上，Manager可以单独部署一台机器，监控100+以上master，总服务器数量不会有太大增加。需要注意的是Manager也可以运行在slaves中的一台机器上。

8 性能无影响

当监控master，MHA只是几秒钟（默认3秒）发送ping包，不发送大的查询。主从复制性能不受影响

9 适用任何存储引擎

Mysql不仅仅适用于事务安全的innodb引擎，在主从中适用的引擎，MHA都可以适用。即使用遗留环境的mysiam引擎，不进行迁移，也可以用MHA。

 

==============****=================***================

一、简介

学习一个高可用小软件，不但要熟悉其功能，还要了解其架构及工作原理。

1. 架构

从架构上来说，MHA分为如下两大部分：

（1） Node

我们知道，MHA是基于MySQL Replication环境的，在该环境中，不管是Master角色，还是Slave角色，都称为Node，是被监控管理的对象节点。

Node服务器上需要安装MHA Node包。

（2） Manager

Manager为MHA架构中的管理者，建议部署在一台独立的服务器上，当然也可部署在某个Slave上，但该Slave永远不要被选择成为新的Master，否则故障切换后的MHA架构就失去了高可用性。

Manager服务器需要安装MHA Manager包，并完善一个主配置文件。

一个Manager可管理多套MySQL Replication环境。

2. 工作原理

相较于其它HA软件，MHA的目的在于维持MySQL Replication中Master库的高可用性，其最大特点是可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。

基本工作流程大致如下：

（1） Manager定期监控Master，监控时间间隔由参数ping_interval决定，缺省为3秒钟一次；可利用其自身的监控功能，也可调用第三方软件来监控；MHA自身提供了两种监控方式：SELECT（执行SELECT 1）和CONNECT（创建连接/断开连接），由于参数ping_type决定，缺省为SELECT方式。

（2） 当监测到Master故障时，调用SSH脚本对所有Node执行一次检查，包括如下几个方面：

――MySQL实例是否可以连接；

――Master服务器是否可以SSH连通；

――检查SQL Thread的状态；

――检查哪些Server死掉了，哪些Server是活动的，以及活动的Slave实例；

――检查Slave实例的配置及复制过滤规则；

――最后退出监控脚本并返回代表特殊意义代码。

（3） 开始Master故障切换，包括如下几个子阶段：

――Phase 1: Configuration Check Phase

在这个阶段，若某个Slave实例的SQL Thread停止了，则会自动启动它；并再次确认活动的Servers及Slaves。

――Phase 2: Dead Master Shutdown Phase

在这个阶段，首先调用master_ip_failover_script，若HA是基于VIP实现的，则关闭VIP，若是基于目录数据库实现的，则修改映射记录。

然后调用shutdown_script脚本强制关闭主机，以避免服务重启时，发生脑裂。

――Phase 3: Master Recovery Phase

又包括如下3个子阶段：

Phase 3.1: Getting Latest Slaves Phase

检查各个Slave，获取最近的和最旧的binary log file和position，并检查各个Slave成为Master的优先级，依赖于candidate_master、no_master、[server_xxx]顺序、binary log差异量等因素。

Phase 3.2: Saving Dead Master's Binlog Phase

若dead master所在服务器依然可以通过SSH连通，则提取dead master的binary log，提取日志的起点就是上一步获取的最新的binary log file和position&#