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..
在检查配置信息的过程中，会再次确认主库状态（double check），同时罗列出当前架构中各主机的状态（Dead | Alive）。
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..
通过show slave status;命令输出的{Master_Log_File,Read_Master_Log_Pos}值，对所有从库进行比较，从而选出latest slaves。
Phase 3.2: Saving Dead Master’s Binlog Phase..
在主库上执行以下命令获得latest 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
然后，monitor server通过scp将生成的差异binlog文件拷贝到本地。最后，还判断了所有从库主机的SSH连接是否可达。
（Note: 这里生产的binlog并非简单的需要执行sql语句，通过mysqlbinlog可以看到它的内容是一个完整格式的binlog，是由格式描述部分事件（Pos:1 to 106）和差异事件（Pos: Read_Master_Log_Pos to tail）组成。）
Phase 3.3: Determining New Master Phase..
执行如下命令，找出latest slave，并确认relay log是否为最全的（即为最接近主库日志的），最后根据候选规则，选出新的主库（会检查是否有设置candidate_master=1和no_master=1），确定failover之后新的复制架构：
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..最快乐的时候，就是去旅行。
