MHA自动Failover过程解析

MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案，来保证数据库系统的高可用。近期，在田老师的推动下，开始一步步深入了解这个HA方案，并也计划在公司线上尝试部署。下面的东西是这段时间的学习笔记和个人理解，没有具体的实战经验，只是人为测试模拟故障的发生，通过日志来分析MHA背后的自动切换过程。

首先，介绍下它的一些特点，以及为什么用它，在哪种场合更适合用它。

1. 10-30s实现master failover（9-12s可以检测到主机故障，7-10s可以关闭主机避免SB，在用很短的时间应用差异日志）

2. 部署简单，无需对现有M-S结构做任何改动（至少3台，保证切换后仍保持M-S结构）

3. 支持手动在线切换（主机硬件维护），downtime几乎很短0.5-2s

4. 保证故障切换后多从库数据的一致性

5. 完全自动化的failover及快速复制架构恢复方案（一主多从）

6. 恢复过程包括：选择新主库、确认从库间relay log差异、新主库应用必要语句、其他从库同步差异语句、重新建立复制链接

上面是我对wiki里面信息的剪辑归纳。在实际测试中，手动切换与自动切换所需时间都能控制在他所描述的范围呢。在一主多从的情况下，当主库故障，需要提升一台从库作为新的主库，其余从库则需要重新指向新的主库建立复制，亲身过这个恢复过程的同志，应该记忆深刻，又费时又费事的（想想有3-4个从库在哪儿等着你0_0…）。可能你会说不是有这样的结构吗：M-m-S(n)，大M掉了，可以马上指向小m，但是这个结构也存在致命的问题，如果是小m遇到点什么意外，后面拖家带口的S可就瞎眼了，这也是为什么大家都很渴望的一个特性（global transaction ID）出现的原因。MHA可以很好的帮我们解决从库数据的一致性问题，同时最大化挽回故障发生后的数据。

接下，我们了解下MHA方案里的两个角色。

node host：原有的MySQL复制结构中的主机，至少3台，即1主2从，当master failover后，还能保证主从结构；只需安装node包。

manager server：运行监控脚本，负责monitoring 和 auto-failover；需要安装node包和manager包。

MHA manager server可以是专门的一台机器，这样所有的业务线上的MHA都可以由其统一监控，配置文件也便于统一管理；或者为了节省机器，可以从现有复制架构中选一台“闲置”从库作为manager server，比如：某台从库不对外提供读的服务，只是作为候选主库，或是专门用于备份。

下面有价值的部分开始了，我将带着大家一步一步的分析整个failover的过程，使大家对MHA有个清晰了解，如果是我们自己的脚本又是如何去实现的呢。

背景介绍

主从结构：

10.0.1.48(master)

———- 10.0.1.37(slave1)

———- 10.0.1.38(slave2)

Sysbench主机：10.0.1.49:: master manager monitor

在sysbench压测机上持续对主库发起更新，通过关闭其中一个主库的IO_THREAD，造成个从库之间的跟新差异，最后暴力kill掉mysqld进程，引起自动master failover发生。

模拟故障

Step1: 10.0.1.49

# sysbench -mysql-host=10.0.1.48

Step2: 10.0.1.37 (1min later)

mysql> stop slave io_thead;

Step3: 10.0.1.37(around 10min later)

mysql> start slave io_thread;

Step4: 10.0.1.48

# killall -9 mysqld_safe mysqld

Failover过程分析

当master_manager监控到主库mysqld服务停止后，首先对主库进行SSH登录检查（save_binary_logs -command=test），然后对mysqld服务进行健康检查（PING(SELECT)每个3秒检查一次，持续3次），最后作出Master is down!的判断，master failover开始。

Phase 1: Configuration Check Phase..

确认主从主机状态，从库中最新的主机有哪些。

Phase 2: Dead Master Shutdown Phase..

前提是你需要指定相关的脚本，比如：master_ip_failover_script、shutdown_script，在安装包的samples/scriptes目录下。

Phase 3: Master Recovery Phase..

Phase 3.1: Getting Latest Slaves Phase..

根据从库同步主库的binlog的位置，分出latest slaves和oldest slaves。

Phase 3.2: Saving Dead Master’s Binlog Phase..

在主库上执行以下命令获得lastest slave与master间的binlog差异：

save_binary_logs -command=save -start_file=mysql-bin.000010  -start_pos=3716 -binlog_dir=/data/mha_48 -output_file=/var/log/masterha/saved_master_binlog_from_10.0.1.48_3306_20120326174946.binlog -handle_raw_binlog=1 -disable_log_bin=0 -manager_version=0.53

然后，通过scp将生成的差异binlog文件拷贝到monitor server上。

Phase 3.3: Determining New Master Phase..

执行如下命令，找出latest slave，并确认relay log是否全部应用，最后根据候选规则，选出新的主库（会检查是否有设置candidate_master=1和no_master=1）：

apply_diff_relay_logs -command=find -latest_mlf=mysql-bin.000019 -latest_rmlp=238437084 -target_mlf=mysql-bin.000019 -target_rmlp=116056791 -server_id=1 -workdir=/var/log/masterha -timestamp=20120330124742 -manager_version=0.53 -relay_log_info=/data/mha_38/relay-log.info  -relay_dir=/data/mha_38/

Phase 3.4: New Master Diff Log Generation Phase..

新主库需要判断自己的relay log是否与latest slave有差异，产生差异relay log；之后Monitor server会通过scp将主库差异binlog拷贝到新主库上。

Phase 3.5: Master Log Apply Phase..

在新主库上应用relay log差异和主库binlog差异；最后，获得新主库的binlog文件及位置信息，并设置read_only=0。

Phase 4: Slaves Recovery Phase..

Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..

判断从库与lastest slave是否存在relay log差异，在latest slave上执行如下命令，生成差异relay log文件，并通过scp拷贝到对应的从库上：

apply_diff_relay_logs -command=generate_and_send -scp_user=root -scp_host=10.0.1.37 -latest_mlf=mysql-bin.000019 -latest_rmlp=238437084 -target_mlf=mysql-bin.000019 -target_rmlp=116056791 -server_id=1 -diff_file_readtolatest=/var/log/masterha/relay_from_read_to_latest_10.0.1.37_3306_20120330124742.binlog -workdir=/var/log/masterha -timestamp=20120330124742 -handle_raw_binlog=1 -disable_log_bin=0 -manager_version=0.53 -relay_log_info=/data/mha_38/relay-log.info  -relay_dir=/data/mha_38/

Phase 4.2: Starting Parallel Slave Log Apply Phase..

首先，将monitor server上生成的binlog差异拷贝到个从库上；

然后，判断从库执行relay log位置（Exec_Master_Log_Pos）是否与已读到的relay log位置（Read_Master_Log_Pos）一致，执行以下命令获得差异文件：

save_binary_logs -command=save -start_file=relay-bin.000003  -start_pos=33701765 -output_file=/var/log/masterha/relay_from_exec_to_read_10.0.1.37_3306_20120330124742.binlog -handle_raw_binlog=1 -disable_log_bin=0 -manager_version=0.53 -relay_log_info=/data/mha_37/relay-log.info  -binlog_dir=/data/mha_37/

接下来，应用所有差异日志，同时差异日志文件合并到一个文件（total_binlog_for_10.0.1.37_3306.20120330124742.binlog）中，执行的语句及结果会被输出一个标有err的日志文件（relay_log_apply_for_10.0.1.37_3306_20120330124742_err.log）中：

apply_diff_relay_logs -command=apply -slave_user=root -slave_host=10.0.1.37 -slave_ip=10.0.1.37  -slave_port=3306

-apply_files=/var/log/masterha/relay_from_exec_to_read_10.0.1.37_3306_20120330124742.binlog, \

/var/log/masterha/relay_from_read_to_latest_10.0.1.37_3306_20120330124742.binlog, \

/var/log/masterha/saved_master_binlog_from_10.0.1.48_3306_20120330124742.binlog \

-workdir=/var/log/masterha -target_version=5.1.57-log -timestamp=20120330124742 -handle_raw_binlog=1 -disable_log_bin=0 -manager_version=0.53 -slave_pass=xxx

最后，执行reset slave，并重新CHANG MASTER。

Phase 5: New master cleanup phease..

执行reset slave操作清除之前slave信息。

以上每个阶段的分析，是根据master_manager监控脚本的输出日志分析得来，它的日志非常详细。看着日志不停的感叹，如此严谨细致的方案；从故障的反复确认，到binlog/relay日志的层层比对，多重差异日志的应用，到最后复制位置的准确选择做得每一步都是十分仔细，如果中途有意外发生会终止failover操作，并产生mha_manager.failover.error的文件，下一次必须要删除该文件才能正常failover，再或是当从库的差异日志太大落后太多（100M），默认情况会终止failover随后报错退出，除非设置check_repl_relay=0，因为它要保证快速切换，downtime不能过长。

其实，在这个方案里面还有好多好多我们只得学习的地方，比如，关于binlog/relaylog文件中的信息，还有show slave status的输出信息，想说的真是太多了，大家可以从以下两个地方获得更加详尽的介绍。

非常非常详尽的文档：http://code.google.com/p/mysql-master-ha/wiki/TableOfContents?tm=6

非常非常有料的PPT：http://www.slideshare.net/matsunobu/automated-master-failover/

最后，再次感叹下，我们不得不佩服老外们对于技术的精益求精，对于事情认真严谨的态度。

建议继续学习：