【译】mysql-master-ha Overview

MHA是一个日本大牛故障切换工具（项目主页：http://code.google.com/p/mysql-master-ha/），本文为项目wiki中Overview这篇文章（Overview）。

概述

主要目的是自动master故障转移，并能在极短的停机时间内(通常是10-30秒）将slave晋升为master，在不改变现有架构、不增加设备投入、复杂性和性能损耗的情况下避免了复制一致性问题。此外，MHA也提供了可调度的在线master的切换：安全得从一个运行着的master切换到新的master上，系统故障停机时间（仅阻塞写入操作）非常低（0.5-2秒）。

MHA的应用场景

MHA提供了下面的功能，在高可用性、数据完整性，不间断master维护等场景中非常有效。

(1). 自动master监控和故障转移

MHA具有监控MySQL环境中master，检测master失效并自动完成master故障转移的功能。即使有些slave没有接受到最新的relay log事件信息，MHA自动从最新的slave中找到relay log，并应用到其他的slave中。这样所有的slave都会一致。MHA通常在数秒内完成故障转移操作——9-12秒来检测master失效，7-10秒来关闭master主机以避免脑裂（可选），以及数秒来在新master上应用relay log，所有整体的故障离线时间为10-30秒。另外，你可以在配置文件中通过设定优先级来将特定的slave来作为master候选者。当MAH修复slave之间的一致性后，你可以将任意slave晋升为新的master，可能导致复制失败的一致性问题将不存在。

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

你也可以在不监控master的情况下，直接使用MHA进行故障转移，并以交互式模式完成。

(3). 非交互式master故障转移

MHA同样支持非交互式master故障转移（不监控master，但是完成failover的故障转移）. 这个特性在你已经监控mysql工具的过程中十分有效。例如，你可以使用Pacemaker(Heartbeat)来监控master失效和虚拟IP地址接管，并使用MHA完成master的故障转移和以及slave的晋升。

(4). 自动master切换到不同的主机上

在很多场景中，迁移一个已有的master到新的主机非常有必要。这虽然不是master的崩溃，但是这种可调度的master维护任务（Scheduled master maintenance）是很有必要的。该任务会导致一定的故障离线时间（至少是阻塞写入）所以必须尽快完成。另一方面，你必须非常小心地阻塞/杀掉当前的活跃会话，因为这可能导致不同master之间的一致性问题（例如：”master1上更新，master2上更新，master1上提交，master2上提交失败”会最终导致数据不一致）。所以需要快速master切换和阻塞写操作。MHA提供了一种实现方法，你可以在0.5-2秒阻塞写入的情况下切换master。大多数场景中，0.5-2秒写入停机时间是可接受的，你可以切换master即时不事先分配可调度的维护窗口。这意味着你可以更容易地实施诸如升级到高版本、切换到更快的服务器等操作。

故障转移中的难题

master的故障转移并非它看起来那么简单。拿最典型的MySQL部署用例来说——一个master带多个slave，如果master崩溃，你需要选择一个最新的slave并将其晋升为新的master，启动其他的slave从新master的复制。这个过程并不简单，即使当前大多数slave的状态都一致，但很可能其他slave还没有接收到它们的二进制日志事件信息。这些slave会在复制连接到新master节点开始时丢失事务，从而导致一致性问题。为了避免这些一致性问题，就需要在在新master上初始化复制之前把丢失的binlog(它们还未到达所有的slave）并依次应用到每一个slave.这个操作非常复杂，手动很难完成。下图是MHA作者在 MySQL Conference and Expo 2011的演讲。

图：Master故障转移:难点何在？
当前大多数MySQL复制用户并没有选择，只能在master崩溃后手动执行，通常会花费几个小时的故障停机时间。这很可能使slave并没有接收到relay log 事件信息，从而导致需要修复的一致性问题。即使Master的崩溃极少发生，但处理的过程是非常痛苦的。
MHA定位于完全自动的master故障转移和尽可能快的恢复过程。恢复的过程包括定位新的master，识别slave之间不同的relay log事件进度，将必要的事件信息应用到新的master上，与其他slave进行同步并在新master上启动复制。MHA通常可以在10-30秒的停机时间内完成这个过程，时间根据复制的延时决定。（10秒来检测master崩溃，可选的7-10秒来关闭master机器以避免脑裂，以及若干秒来执行恢复）。
MHA提供了自动和手动的故障转移命令，自动故障转移命令”masterha_manager (MHA Manager)”包含了master监控和master故障转移，masterha_manager 会不断监控master服务器的可用性，如果MHA Manager发现连不上master服务器，它会自动启动非交互式的故障转移流程。
手动的故障转移命令”masterha_master_switch”在一开始会检查master是否真的挂掉，如果master真挂了，masterha_master_switch 会选择将一个slave晋升为master（你也可以选择一个优先的master），然后它启动恢复和故障转移。当然，它在后台完成了很多操作，但是你只执行一个命令，剩下的操作都会自动为你完成。

^^