MySQL高可用方案-MHA

         MHA是MySQL High Available的缩写，一般指一位日本MySQL大牛用Perl写的一套MySQL故障切换方案，来保证数据库系统的高可用。

         MHA易于安装和部署，不需要改变现有部署，也不影响服务器性能 (1 ping/3s)，而且可以完全部署到Slave上，节约了新服务器的成本。

         如此轻量的部署，就能提供自动监控master和故障转移 (downtime 10~30s)，保障主从数据的一致性 (即使master crash)，并适用于MySQL的任何主从存储引擎。真是超值啊！

         还支持在线切换master，只需要很短的时间(0.5~2s)，此时仅仅阻塞写操作，并不影响读操作，满足几乎无间断的维护需要。

 

MHA优点

master自动监控和故障转移

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

         MHA秒级别故障转移：9-12秒监测到主机故障，任选7秒钟关闭电源主机避免脑裂，接下来apply差异relay logs，注册到新的master。通常整个downtime只需要10-30秒。

         即使有一些slave没有接受新的relaylog events，MHA也会从最新的slave自动识别差异的relay log events，并apply差异的event到其他slaves。因此所有的slave都是一致的。

         另外，在配置文件里可以配置一个slave优先成为master。因为MHA修复了slave之间的一致性，dba就不用去处理一致性问题。

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

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

 

保障主从数据的一致性

         即使mastercrash，MHA会自动识别slave间relay log events的不同，然后应用与不同的slave，最终所有slave都同步。结合半同步一起使用，几乎没有任何数据丢失。

 P.S. 但不能保证0丢失。

非交互式故障转移

         也可以支持不监控master，自动/手动故障转移。这个特性很有用，特别是你已经安装了其他软件监控master。比如，用Pacemaker(Heartbeat)监测master故障和vip接管，用MHA故障转移和slave提升。

 

在线切换master到不同主机

         在很多情况下，有必要将master转移到其他主机上（如替换raid控制器，提升master机器硬件等等）。这并不是master崩溃，但是计划维护必须去做。计划维护导致downtime，必须尽可能快的恢复。

         快速的master切换和优雅的阻塞写操作是必需的，MHA也不例外，其中阻塞写操作一般在0.5-2秒。在很多情况下0.5-2秒downtime是可以接受的，并且即使不在计划维护窗口。这意味着当需要更换更快机器，升级高版本时，DBA可以很容易采取动作。

 

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

         MHA最重要的一个设计理念就是尽可能使用简单。

         使用与5.0+以上主从环境，其他HA方案需要改变MySQL部署设置；而MHA则不需要做这些配置，同步和半同步环境都可以用。

         启动/停止/升级/降级/安装/卸载 MHA都不用改变MySQL主从（如启动/停止）。当要升级MHA到新版本时，不需要停止MySQL，仅仅更新HMA版本，重启MHA Manger即可。

 

不增加服务器费用

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

 

性能无影响

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

 

适用任何存储引擎

         MHA不仅仅适用于事务安全的innodb引擎，而是所有主从引擎都适用。

 

与其他HA方案比较

手动处理

         MySQL的复制有同步，异步和半同步三种模式，一般为了提高性能都不会采用同步的方式。当master崩溃时，很有可能一些slave还没有接受最新的relay log events，这意味着每一个slave都相互处在不同的状态。

         人为地修复一致性的问题会非常麻烦。而且由于一致性的异常，主从也不能正常启动 (duplicate key error)。在手动重启的情况下，往往花费1个小时是很正常的，这成本就太大了。

 

单一主从

         要解决上述一致性的问题，可以只部署单一主从。这样一些slave 落后与其他slave的情况将不会发生。其中一个master崩溃，可以轻松的让应用转移到一个新的master上面，提供对外服务，故障迁移很简单。

         单一主从简单高效，非常便于维护。就是负载量不大，随着应用的扩张，单一必然无法支持。   【适合的就是最好的】

 

一主一备，多从 (双主多从) Master,one candidate master, and multiple slaves

         双主多从的架构也很常见。主master挂掉，备用master将接替主master提供服务。某些情况配置为多主架构。

         但这只是作为master故障转移方案。而数据一致性还没得到解决，当前master挂掉，剩余slave不一定接受全部relay log events。

         这种架构使用广泛，其中一个通用的方案Pecemaker(Heartbeat)+DRBD+MySQL：

双master，其中一个master只读，每个master都至少有一个slave。

                  M(RW)--M2(R)

                      |              |

                  S(R)      S2(R)

         但也会存在下面几个问题：

l  1 费用，特别是跑大量主从环境。Pecemaker+DRBD是主动/被动的解决方案，因此需要一台被动服务器对外不提供任何应用服务。基本的需要四台MySQL服务器，one active master，one passive master，two slaves。

l  2 宕机时间(downtime)。Pacemaker+DRBD是主备集群，主master挂掉，备用master启用。这可能花费长的时间，特别是没有用innodb plugin。即使用innodb plugin，花费几分钟开始在备用master上接受连接也不寻常。另外，因为备用master上数据/文件缓存是空的，恢复时间，热身(填充数据到data buffer pool)花费不可忽视的时间。实践中，需要一台或更多slave提供足够的读服务。在热身时间内，空缓存导致写性能降低

l  3 写性能下降和一致性问题。为了让主动/被动集群真正的工作，每次提交(commit)后，必须刷新事务日志(binary log和innodb log)，会降低写性能。另外，slave和备份master的同步机制(刷日志)不一样，导致活动master crash的时候，slave和备份master可能会出现一致性的问题。

MySQL Cluster

         MySQL cluster是真正的高可用解决方案，但是必须得用NDB存储引擎。如果你用innodb，将不能发挥MySQL cluster集群优势。

 

半同步复制 Semi-Synchronous Replication

         半同步复制大大降低了binlogevent仅仅存在于崩溃master上的这种风险。这非常有用的能避免数据丢失。但是半同步不能解决所有一致性问题，只能保证一个（不是所有）slave接受到master端的commit的binlog events，其他slave也许还没有接受全部的binlog events。

         所以，如果不能从新的slave来apply不同的binlogevents到其他slave上，也就不能保证相互一致性。

 

Global Transaction ID

         GlobalTransactionID所要达到的目的跟MHA相同，但它覆盖更多。MHA只是两级复制，但是global transaction id覆盖任何级别的复制环境，即使第两级复制失败，dba也能覆盖第三级。Check Google'sglobal transaction id project for details。

         原文出处：http://blog.csdn.net/aeolus_pu/article/details/9127897