MHA自动Failover过程解析

╰半夏微凉° 2022-08-18 02:12 213阅读 0赞

[**MHA**][MHA]是一位[**日本MySQL大牛**][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**][http_code.google.com_p_mysql-master-ha_wiki_TableOfContents_tm_6]

非常非常有料的PPT：[**http://www.slideshare.net/matsunobu/automated-master-failover/**][http_www.slideshare.net_matsunobu_automated-master-failover]

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

[MHA]: http://code.google.com/p/mysql-master-ha/
[MySQL]: http://yoshinorimatsunobu.blogspot.com/
[http_code.google.com_p_mysql-master-ha_wiki_TableOfContents_tm_6]: http://code.google.com/p/mysql-master-ha/wiki/TableOfContents?tm=6
[http_www.slideshare.net_matsunobu_automated-master-failover]: http://www.slideshare.net/matsunobu/automated-master-failover/