浅谈秒级故障切换！用MHA轻松实现MySQL高可用（一）

MHA简介

MHA是由日本人youshimaton（原就任于DeNA，现就任于FaceBook）开发的比较成熟的MySQL高可用方案。MHA可以在30秒内实现故障切换，并能在故障切换中，最大可能的保证数据一致性。目前淘宝也正在开发类似产品TMHA，目前已支持一主一从。

MHA架构

MHA由MHA Manager和MHA Node组成。以下图：

MHA Manager

运行一些工具，好比masterha_manager工具实现自动监控MySQL Master和实现master故障切换，其它工具实现手动实现master故障切换、在线mater转移、链接检查等等。一个Manager能够管理多个master-slave集群。

MHA Node

部署在全部运行MySQL的服务器上，不管是master仍是slave。主要做用有三个。

Ⅰ、保存二进制日志

若是可以访问故障master，会拷贝master的二进制日志

II、应用差别中继日志

从拥有最新数据的slave上生成差别中继日志，而后应用差别日志。

III、清除中继日志

在不中止SQL线程的状况下删除中继日志

MHA工做原理

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

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

 

当前高可用方案

• Heartbeat+DRBD

开销：须要额外添加处于被动状态的master server（并不处理应用流量）

性能：为了实现DRBD复制环境的高可用，innodb-flush-log-at-trx-commit和sync-binlog必须设置为1，这样会致使写性能降低。

一致性：在master上必要的binlog时间可能会丢失，这样slave就没法进行复制，致使产生数据一致性问题。

• MySQL Cluster

MySQL Cluster真正实现了高可用，可是使用的是NDB存储引擎，而且SQL节点有单点故障问题。

• 半同步复制(5.5+)

半同步复制大大减小了“binlog events只存在故障master上”的问题。

在提交时，保证至少一个slave（并非全部的）接收到binlog，所以一些slave可能没有接收到binlog。

• 全局事务ID

在二进制文件中添加全局事务ID（global transaction id）须要更改binlog格式，在5.1/5.5版本中不支持。

在应用方面有不少方法能够直线全局事务ID，可是仍避免不了复杂度、性能、数据丢失或者一致性的问题。

• PXC

PXC实现了服务高可用，数据同步时是并发复制。可是仅支持InnoDB引擎，全部的表都要有主键。锁冲突、死锁问题相对较多等等问题。

 

MHA的优点

一、故障切换快

在主从复制集群中，只要从库在复制上没有延迟，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秒内完成故障切换是不可能的。

二、master故障不会致使数据不一致

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

三、无需修改当前的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上，因此并不须要迁移。

四、无需增长大量的服务器

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

五、无性能降低

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

六、适用于任何存储引擎

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