允许转载, 转载时请以超链接形式标明文章原始出处和网站信息

MHA自动Failover过程解析(updated)

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

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

1. 10-30s实现master failover9-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 slavemaster间的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..

等待新主库将relay log中已复制过来的语句执行完毕,通过比较Exec_Master_Log_Pos和Read_Master_Log_Pos进行确认;然后,在新主库上应用relay log差异和主库binlog差异;最后,获得新主库的binlog文件及位置信息,并设置read_only=0。

Phase 4: Slaves Recovery Phase..

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

判断从库与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/

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

(Note: 该阶段的操作是在所有从库上并行执行。生成的total_binlog是将所有差异Binlog内容的合并,而非执行mysqlbinlog命令得到输出结果的合并。)

Phase 5: New master cleanup phease..

执行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 #

13 comments to MHA自动Failover过程解析(updated)

  • 位鹏飞

    你好,请留下联系方式,有问题想请教!

  • 位鹏飞

    你好,想请教一个问题:我打算用把APP联接数据库的配置文件信息,放在zookeeper中,这个可以实现,但是对于 虚拟ip的话,不知你是怎么做的?能否分享一下吗?

    • MHA是对native-repl(M[W/R]–>S[R])做的意外故障处理,我们业务数据库采用DNS域名的方式给前端提供访问,在发生auto-failover之后,需要手动执行脚本直接跟新DNS中的A记录。你说道的VIP使用,我理解的是,在M(active)–>M’(standby)结构中通常可以采用VIP,在对外提供访问时,但只能有一个节点对外提供服务,当故障发生后,VIP会从M飘到M’上继续无差异化对外服务,就是说在种【单向】复制结构中,只允许VIP后的一个节点对外提供服务。 (P.S:我完全不了解zookeeper:P)

  • Donghui

    我想问下…我测试的时候出了点问题…麻烦能邦我看一下么…

    切换的时候报错:
    [error][/usr/lib/perl5/site_perl/5.8.8/MHA/ManagerUtil.pm, ln178] Got ERROR: Use of uninitialized value in scalar chomp at /usr/lib/perl5/site_perl/5.8.8/MHA/ManagerConst.pm line 90.

  • yyj

    请问:Phase 3.2: Saving Dead Master’s Binlog Phase..
    此时需要到主库查看binlog
    但如果主库整个挂掉(无法登录主库服务器)
    会怎么样?

  • 阿飞

    博主有没有遇到这种情况:
    Master挂掉后MHA会做故障处理,会将其中一个slave(备库)提升为新的Master(其他处理就不说了),但是我发现Master挂掉后MHA的mansger也会挂掉,直到原来的Master恢复后才能正常启动。这个时候Manager节点已经无法继续监控了。

    不知道你有没遇到类似这样的情况呢?如何解决的呢?求解。谢谢!~

    • Hi 阿飞,
      当master故障,manager检测到会触发auto-failover,成功切换后,manager进程会结束监控,如果你还想让manager继续监控新的主从架构,就需要修改你的选项–conf指定的文件(因为之前conf文件对应故障前的主从架构),将故障master的那段group注释掉,然后再重启manager监控。

      • 阿飞

        Hi 谢谢你的回复:)按照目前我的操作来的看的话,和你说的基本一致。不过经你这么解释,我明白了MHA Manager的工作流程,如果发生故障那还是需要手动来处理这个过程,我想的是MHA有没有可以更自动化的工具来处理类似的情况,呵呵。楼主有做故障方面的预警吗?

        • 我又仔细看了下wiki,里面提到masterha_manager有一个参数–remove_dead_master_conf可以自动帮我们做故障切换后,将故障master的配置信息从conf文件中清除,后续直接再次启动manager监控即可。

  • shi

    能否master_ip_failover的脚本分享下,由于我这边架构为1台master+多台slave,我暂时没有vip,所以想请教下,我后续搭建的时候,我如何去写这个脚本?如何确认我的VIP分配到新的某台设备上?以什么为基准或者应该是某个脚本去调用吗?》

路过踩一脚

 

 

 

能使用 these HTML 标签

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">