MySQL中MHA有什么用

共计 4599 个字符，预计需要花费 12 分钟才能阅读完成。

这篇文章给大家分享的是有关 MySQL 中 MHA 有什么用的内容。丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，一起跟随丸趣 TV 小编过来看看吧。

概述
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。

感谢各位的阅读！关于“MySQL 中 MHA 有什么用”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！