标签：
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开始。
在检查配置信息的过程中，会再次确认主库状态（double check），同时罗列出当前架构中各主机的状态（Dead | Alive）。
接下来是处理故障主库，该阶段可以通过定义的脚本，将前端的请求转移到新的主库上或是将故障主库的主机关掉以避免脑裂带来数据不一致问题；但前提是 你需要指定相关的脚本，比如：master_ip_failover_script、shutdown_script，在安装包的 samples/scriptes目录下。
通过show slave status;命令输出的{Master_Log_File,Read_Master_Log_Pos}值，对所有从库进行比较，从而选出latest slaves。
在主库上执行以下命令获得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）组成。）
执行如下命令，找出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/
新主库需要判断自己的relay log是否与latest slave有差异，产生差异relay log；之后Monitor server会通过scp将主库差异binlog拷贝到新主库上。
等待新主库将relay log中已复制过来的语句执行完毕，通过比较Exec_Master_Log_Pos和Read_Master_Log_Pos进行确认；然后，在新主库 上应用relay log差异和主库binlog差异；最后，获得新主库的binlog文件及位置信息，并设置read_only=0。
判断从库与latest 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/
首先，将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。
（Note: 该阶段的操作是在所有从库上并行执行。生成的total_binlog是将所有差异Binlog内容的合并，而非执行mysqlbinlog命令得到输出结果的合并。）
执行reset slave操作清除之前slave信息。
以上各阶段的分析，是根据master_manager监控脚本的输出日志分析得来，failover的输出日志非常详细。在研究日志的过程中不禁 感叹，MHA是一个如此严谨细致的方案；从故障的反复确认，到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/
最后，再次感叹下，我们不得不佩服老外们对于技术的精益求精，对于事情认真严谨的态度。
Thanks so much, Yoshinori Matsunobu!!!
# latest updated by 2012-06-18 #
标签：
原文地址：http://www.cnblogs.com/zengkefu/p/5497009.html
