MHA特性

1.主服务器的自动监控和故障转移

MHA监控复制架构的主服务器，一旦检测到主服务器故障，就会自动进行故障转移。即使有些从服务器没有收到最新的relay log，MHA自动从最新的从服务器上识别差异的relay log并把这些日志应用到其他从服务器上，因此所有的从服务器保持一致性了。MHA通常在几秒内完成故障转移，9-12秒可以检测出主服务器故障，7-10秒内关闭故障的主服务器以避免脑裂，几秒中内应用差异的relay log到新的主服务器上，整个过程可以在10-30s内完成。还可以设置优先级指定其中的一台slave作为master的候选人。由于MHA在slaves之间修复一致性，因此可以将任何slave变成新的master，而不会发生一致性的问题，从而导致复制失败。

2.交互式主服务器故障转移

可以只使用MHA的故障转移，而不用于监控主服务器，当主服务器故障时，人工调用MHA来进行故障故障。

3.非交互式的主故障转移

不监控主服务器，但自动实现故障转移。这种特征适用于已经使用其他软件来监控主服务器状态，比如heartbeat来检测主服务器故障和虚拟IP地址接管，可以使用MHA来实现故障转移和slave服务器晋级为master服务器。

4.在线切换主服务器

在许多情况下，需要将现有的主服务器迁移到另外一台服务器上。比如主服务器硬件故障，RAID控制卡需要重建，将主服务器移到性能更好的服务器上等等。维护主服务器引起性能下降，导致停机时间至少无法写入数据。另外，阻塞或杀掉当前运行的会话会导致主主之间数据不一致的问题发生。MHA提供快速切换和优雅的阻塞写入，这个切换过程只需要0.5-2s的时间，这段时间内数据是无法写入的。在很多情况下，0.5-2s的阻塞写入是可以接受的。因此切换主服务器不需要计划分配维护时间窗口(呵呵，不需要你在夜黑风高时通宵达旦完成切换主服务器的任务)。

注：MHA可以应用于任何复制结构

二． MHA所需条件

1.SSH公钥验证

MHA管理节点通过ssh连接mysql服务器，MHA节点通过scp发送最新的relay log到其他slaves服务器上。为了使这些过程自动化，使用SSH公钥验证密码。

2.操作系统

MHA目前只支持Linux系统

3.单台可写主服务器和多台从服务器或只读主服务器

当主服务器当掉时，MHA修复从服务器之间数据一致性。MHA试图从当掉的主服务器上保存尚未发送的二进制日志文件并应用于所有从服务器。如果只有一个从服务器，就不需在意从服务器之间一致性问题。即使只有一个从服务器，MHA也会从当掉的主服务器上保存尚未发送的二进制日志事件只要能通过ssh访问到主服务器。使用半同步复制可以解决当主服务器当掉后，无法ssh到主服务器上保存尚未发送的二进制日志事件。

从MHA Manager0.52版本开始，支持多主复制结构。只允许其中一台主服务器可写，其他主服务器必须设置read-only=1。默认情况下，被管理服务器应该是两层复制结构。

4.在三层或三层以上复制情况下

默认情况下，MHA不支持三层或三层以上的复制结构。如master1—master2—-slave3。MHA故障转移和恢复是直接从从服务器中选择一台作为当前的主主服务器。MHA可以管理master1和master2，当master1当掉后，将master2作为主，MHA不会监控和恢复slave3因为slave3是从不同的主服务器上(master2)复制的。为了使MHA工作在这种架构下，需要做如下设置：

只在MHA配置文件中配置master1和master2

在MHA配置文件中所有主机上设置multi_tier_slave=1

在这种情况下，MHA只管理主主服务器和二层的从服务器，在故障转移过程中，三层从服务器仍然可以正常工作的。

5.mysql版本5.0或更高

MHA支持mysql5.0或以上版本。因为从mysql5.0版本起二进制日志格式(binlog v4格式)改变了。当MHA解析二进制日志来确定目标中继日志位置，是使用v4格式的。MySQL版本不得低于5.0.60。

6.mysqlbinlog版本3.3或更高

MHA在目标从服务器上应用二进制事件使用mysqlbinlog。如果主服务器使用基于行格式复制，基于行格式的事件写入到二进制文件中，这种二进制日志格式的文件只能被MySQL5.1或更高版本的mysqlbinlog解析。MySQL5.0.60以下版本中的mysqlbinlog不支持基于行格式的。

7.候选主服务器log-bin必须开启

如果当前的从服务器没有开启log-bin，那么将不可能成为主服务器。MHA管理节点会检测是否有配置log-bin。如果当前所有从服务器都没有设置log-bin，那么MHA不进行故障转移。

即配置文件中log-slave-updates

8.所有服务器上的二进制日志和中继日志过滤规则必须相同

binlog-do-db和replicate-ignore-db设置必须相同。MHA在启动时候会检测过滤规则，如果过滤规则不同，MHA不启动监控和故障转移。

binlog-do-db                  需要复制的数据库名，如果复制多个数据库，重复设置这个选项即可

binlog-ignore-db           不需要复制的数据库苦命，如果复制多个数据库，重复设置这个选项即可

replicate-do-db              需要复制的数据库名，如果复制多个数据库，重复设置这个选项即可

replicate-ignore-db         需要复制的数据库名，如果复制多个数据库，重复设置这个选项即可

9.候选主服务器上的复制用户必须存在

当故障转移后，所有从服务器上将执行change master to命令。

10.保留中继日志和定期清理

中继日志

MySQL在从节点上使用了一组编了号的文件，这组文件被称为中继日志。当SQL线程把那些数据复制发生的变更应用到从节点时，中继日志将会负责保存这些变更。中继日志文件是按照编码顺序排列的，从000001开始，包含所有当前可用的中继文件的名称。中继日志的格式和MySQL二进制日志的格式一样，从而更容易被mysqlbinlog客户端实用程序读取。

默认情况下，从服务器上的中继日志在SQL线程执行完后会被自动删除的。但是这些中继日志在恢复其他从服务器时候可能会被用到，因此需要禁用中继日志的自动清除和定期清除旧的中继日志，mha就是默认禁用的。定期清除中继日志需要考虑到复制延时的问题。在ext3文件系统下，删除大的文件需要一定的时间，会导致严重的复制延时。为了避免复制延时，暂时为中继日志创建硬链接。

MHA节点包含pure_relay_logs命令工具，它可以为中继日志创建硬链接，执行SET GLOBAL relay_log_purge=1，等待几秒中以便SQL线程切换到新的中继日志，再执行SET GLOBAL relay_log_purge=0。

pure_relay_logs参数如下所示：

–user mysql用户名

–password mysql密码

–host mysql服务器地址

–port 端口号

–workdir 创建和删除中继日志硬链接目录。成功执行脚本后，硬链接的中继日志文件将被删除。默认目录是/var/tmp。

–disable_relay_log_purge 如果relay_log_purge=1，purge_relay_logs脚本将退出不做任何事情。设置–disable_relay_log_purge参数，purge_relay_logs脚本不会退去，且自动设置relay_log_purge=0。

定期执行purge_relay_logs脚本：

Purge_relay_logs脚本删除中继日志不会阻塞SQL线程。因此在每台从服务器上设置计划任务定期清除中继日志。

00 00 * * * /usr/bin/purge_relay_logs –user=root –password=passwd –disable_relay_log_purge >> /data/masterha/log/purge_relay_logs.log 2>&1

最好在每台从服务器上不同时间点执行计划任务。

11. LOAD DATA INFILE不要使用基于语句型的二进制日志

如果使用非事务性存储引擎，在执行完LOAD DATA INFILE基于语句型二进制日志时，主服务器当掉，MHA可能不会产生差异的中继日志事件。使用LOAD DATA INFILE基于语句型二进制日志有一些已知问题，在mysql5.1版本中不建议使用，同时还会引起严重的复制延时，因此没有理由使用它。