【摘要】MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案，来保证数据库系统的高可用。在宕机的时间内（1030秒内），完成故障切换，部署MHA

MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案，来保证数据库系统的高可用。在宕机的时间内（1030秒内），完成故障切换，部署MHA，可避免主从一致性问题，节约购买新服务器的费用，不影响服务器性能，易安装，不改变现有部署。MHA还支持在线切换，从当前运行master切换到一个新的master上面，只需要很短的时间（0.52秒内），切换时仅仅阻塞写操作，并不影响读操作，便于主机硬件维护。在有高可用，数据一致性要求的系统上，MHA 提供了强大的功能，几乎无间断的满足维护需要。

优点：

（1）主库自动监控和故障转移

在当前已存在的主从复制环境中，MHA可以监控主库故障，并自动转移故障。即使有一些从库没有接收到新的relay log events，MHA也会从接收过的其他从库中自动识别有差异的relay log events，并在没接收到的从库上进行数据的前滚，以此来保障主从数据的一致性。

MHA可达到秒级别故障转移（9~12秒监测到主库故障，任选7秒钟关闭主库电源主机避免脑裂，接下来对数据不全的从库进行数据的前滚（通过其他完整从库的中继日志relay log）），最后建立新的主库，总停机时间在（total downtime）10~30秒）。另外，在配置文件里可以配置一个从库优先成为主库，因为MHA修复了从库之间的一致性，dba就不用去处理一致性问题。当建立新的主库之后，并行恢复其他从库。即使有成千上万的从库,也不会影响恢复主库时间，从库也很快完成数据同步。

相关推荐：《Python教程》

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

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

MHA可以用来只做故障转移，即不监测主库状态，只作为故障转移的交互。

（3）非交互式故障转移

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

（4）在线切换主库到不同主机

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

（5）master 崩溃不会导致主从数据不一致性

当master 崩溃后，MHA自动识别从库间relay log events的不同，然后应用于不同的从库上，最终所有从库都同步。结合通过半同步一起使用，几乎没有任何数据丢失。

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

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

当你需要升级MHA到新版本时，不需要停止mysql，仅仅更新HMA版本，然后重新启动MHAmanger即可。有些高可用方案要求特定的mysql版本（如mysql cluster，mysql with global transaction id 等）,而且你可能不想仅仅为了MasterHA而迁移应用。很多情况下，公司已经部署了许多传统的mysql应用，开发或dba不想花太多时间迁移到不同的存储引擎或新的特性上。

（7）不增加服务器费用

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

（8）性能无影响

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

（9）适用任何存储引擎

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

架构

在架构上来说，MHA分为两类：

（1）Node

MHA是基于MySQL 主从复制环境的，在该环境中，不管是Master角色，还是Slave角色，都称为Node，是被监控管理的对象节点。Node服务器上需要安装MHA Node包。

（2）Manager

Manager为MHA架构中的管理者，建议部署在一台独立的服务器上，当然也可部署在某个Slave上，但该Slave永远不要被选择成为新的Master，否则故障切换后的MHA架构就失去了高可用性。Manager服务器需要安装MHA Manager包，并完善一个主配置文件。一个Manager可管理多套MySQL 主从复制环境。