mysql高可用方案MHA介绍

mysql高可用方案MHA介绍

 

概述

 

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

 

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

 

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

 

 优点

 

1        master自动监控和故障转移

 

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

 

即使有一些slave没有接受新的relay log events，MHA也会从最新的slave自动识别差异的relay log events，并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。

 

 

 

 与其他HA方案比较

 

Doing everything manually

Mysql replication 是同步或半同步。当master崩溃时，很有可能一些slave还没有接受最新的relay log events，这意味着每一个slave都相互处在不同的状态。人为修复一致性问题显得不再平凡。没有一致性问题，主从也可能不会启动（如duplicate key error）。花费1个多小时重新启动主从复制显得不同寻常。

 

 

 

Single master and single slave

在单一主从情况下，一些slave 落后与其他slave的情况将不会发生。其中一个master崩溃，可以轻松的让应用转移到一个新的master上面，提供对外服务，故障迁移很简单。

 

 

 

Master, one candidate master, and multiple slaves双主多从

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

 

 

 

M(RW)-----M2(R)                      M(RW), promoted from M2

 

       |                                          |

 

  +----+----+          --(master crash)-->   +-x--+--x-+

 

 S(R)     S2(R)                             S(?)      S(?)

 

                                          (Fromwhich position should S restart replication?)

 

但是这并不作为master故障转移方案。当前master挂掉，剩余slave不一定接受全部relay log events，修复数据一致性还是问题。

 

 

 

这种架构使用广泛，但是不是所有人都能深刻理解上述问题。当前master挂掉，slave变得不统一或者slave不能从新的master复制数据。

 

也许双master，其中一个master只读，每个master都至少有一个slave也许可能解决问题。

 

         M(RW)--M2(R)

          |      |

        S(R)   S2(R)

 

 

Pacemaker + DRBD

Pecemaker(Heartbeat)+DRBD+Mysql是一个通用方案。但是这个方案也有以下问题

 

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

 

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

 

3 写问题下降或一致性问题。为了让主动/被动集群真正的工作，每次提交(commit)后，必须刷新事务日志(binary log和innodb log)，也就是必须设置innodb-flush-log-at-trx-commit=1,sync-binlog=1。设置sync-binlog=1会降低写性能，因为fsync()函数被序列化(sync-binlog=1，group commit失效)。大部分案例中，不设置sync-binlog=1.如果没有设置sync-binlog=1，活动master crash，新的master(先前被动服务器)可能会丢失一些已经发送到slave的binary log events。假如 master 挂掉，slave A接受到mysqld-bin.000123,位置1500。binlog data刷新到硬盘的位置在1000，那么新的master数据也只能mysqld-bin.000123的1000处，然后在启动时创建一个新的binary log mysqld-bin.000124。如果发生这种情况，slave A不能继续复制，因为新的master 没有mysqld-bin.000123位置1500.

 

 4 复杂。对多数人来说，安装/初始化pacemake和DRBD不是容易的事情。相对于其他案例，初始化DRBD需要重新创建系统分区也不容易。要求dba在DRBD和linux内核层有足够的技能。如果dba执行了一个错误命令（如执行drbdadm–overwrite-data-of-peer primary 在被动节点），那么将会损坏活动的数据。重要的是另外一旦硬盘io层出现问题，多数dba处理这种问题不是容易的。

 

MySQL Cluster

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

 

Semi-Synchronous Replication

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

 

Global Transaction ID

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