mysql高可用研究(一) 主从+MHA架构

时间 2019-11-19

标签 mysql 可用研究主从 mha 架构栏目 MySQL 繁體版

原文原文链接

最近在研究mysql的高可用架构，本身想总结下经常使用的高可用方案都有哪些、有哪些优缺点以及应用的场景？搞得是头昏脑涨，天昏地暗，看了诸多资料，每次都以为公说公有理婆说婆有理。其实嘛，你们说的都有必定的道理，只不过适合本身的才是最正确的。今天就从比较经常使用的主从+MHA提及。html

学习一种新的架构仍是软件，最好仍是先从了解它的原理开始，这样才能在应用时扬长避短。node

1、【MHA原理】mysql

相较于其它HA软件，MHA的目的在于维持MySQL Replication中Master库的高可用性，其最大特色是能够修复多个Slave之间的差别日志，最终使全部Slave保持数据一致，而后从中选择一个充当新的Master，并将其它Slave指向它。sql

MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明以下。数据库

Manager工具包主要包括如下几个工具：vim

masterha_check_ssh              检查MHA的SSH情况
masterha_check_repl             检查MySQL复制情况
masterha_manger                 启动MHA
masterha_check_status           检测当前MHA运行状态
masterha_master_monitor         检测master是否宕机
masterha_master_switch          控制故障转移（自动或者手动）
masterha_conf_host              添加或删除配置的server信息

Node工具包（这些工具一般由MHA Manager的脚本触发，无需人为操做）主要包括如下几个工具：bash

save_binary_logs                保存和复制master的二进制日志
apply_diff_relay_logs           识别差别的中继日志事件并将其差别的事件应用于其余的slave
filter_mysqlbinlog              去除没必要要的ROLLBACK事件（MHA已再也不使用这个工具）
purge_relay_logs                清除中继日志（不会阻塞SQL线程）

基本工做流程大体以下：服务器

（1） Manager按期监控Master，监控时间间隔由参数ping_interval决定，缺省为3秒钟一次；可利用其自身的监控功能，也可调用第三方软件来监控；MHA自身提供了两种监控方式：SELECT（执行SELECT 1）和CONNECT（建立链接/断开链接），session

主要由ping_type参数决定，默认是select方式。架构

（2）当监测到Master故障时，调用SSH脚本对全部Node执行一次检查，包括以下几个方面：

――MySQL实例是否能够链接；

――Master服务器是否能够SSH连通；

　　 ――检查SQL Thread的状态；

　　 ――检查哪些Server死掉了，哪些Server是活动的，以及活动的Slave实例；

　　 ――检查Slave实例的配置及复制过滤规则；

　　 ――最后退出监控脚本并返回表明特殊意义代码。

（3）开始Master故障切换，包括以下几个子阶段：

　　 ――Phase 1: Configuration Check Phase

在这个阶段，若某个Slave实例的SQL Thread中止了，则会自动启动它；并再次确认活动的Servers及Slaves。

　　 ――Phase 2: Dead Master Shutdown Phase

在这个阶段，首先调用master_ip_failover_script，若HA是基于VIP实现的，则关闭VIP，如果基于目录数据库实现的，则修改映射记录。而后调用shutdown_script脚本强制关闭主机，以免服务重启时，发生脑裂。

　　 ――Phase 3: Master Recovery Phase

　　　又包括以下3个子阶段：

　　　　 Phase 3.1: Getting Latest Slaves Phase

　　　　检查各个Slave，获取最近的和最旧的binary log file和position，并检查各个Slave成为Master的优先级，依赖于candidate_master、no_master、 [server_xxx]顺序、binary log差别量等因素。

　　　　 Phase 3.2: Saving Dead Master's Binlog Phase

　　　　若dead master所在服务器依然能够经过SSH连通，则提取dead master的binary log，提取日志的起点就是上一步获取的最新的binary log file和position，直到最后一条事件日志，并在dead master本地的工做目录（由参数remote_workdir决定）中

建立文件保存这些提取到的日志，而后将该文件拷贝到Manager服务器的工做目录下（由参数manager_workdir决定）。若dead master系统就没法链接，也就不存在差别的binary log了。MHA还要对各个Slave节点进行健康检查，主要是SSH连通性。

　　　　Phase 3.3: Determining New Master Phase

　　　　接下来调用apply_diff_relay_logs命令恢复Slave的差别日志，这个差别日志指的是各个Slave之间的relay log。恢复完成后，全部的Slave数据是一致的，此时就能够根据优先级选择New Master了。

　　　　Phase 3.4: New Master Diff Log Generation Phase

　　　　这里是生成dead master和new master之间的差别日志，即将Phase 3.2保存的binary log拷贝到New Master的工做目录中（remote_workdir）。

　　　　Phase 3.5: Master Log Apply Phase

　　　　将上一步拷贝的差别日志恢复到New Master上，若发生错误，也可手动恢复。而后获取New Master的binlog name和position，以便其它Slave从这个新的binlog name和position开始复制。最后会开启New Master的写权限，即将read_only参数设置为0。

　　 ――Phase 4: Slaves Recovery Phase

　　　　Phase 4.1: Starting Parallel Slave Diff Log Generation Phase

　　　　生成Slave与New Slave之间的差别日志，并将该日志拷贝到各Slave的工做目录下，这部分日志dead master和new master之间差别的那部分日志，由于各个Slave在Phase 3.3阶段已经同步了。

　　　　Phase 4.2: Starting Parallel Slave Log Apply Phase

　　　　在各个Slave上应用这部分差别日志，而后经过CHANGE MASTER TO命令将这些Slave指向新的New Master，最后开始复制(start slave)。

　　 ――Phase 5: New master cleanup phase

　　　　清理New Master其实就是重置slave info，即取消原来的Slave信息。至此整个Master故障切换过程完成。

2、【实验部分】

一、【环境说明】：默认三台机器上都已安装mysql5.6,且主从复制已经配置完成。
角色                 主机名      ip地址       功能
主库                    node1   192.168.245.129    (w/r)
candidate_master       node2   192.168.245.131     (r)
从库                    node3    192.168.245.132    (r)
vip： 192.168.245.100

129为主库，对外提供读写服务，而131和132机器对外提供读服务，须要设置为只读状态，不建议将它写入配置文件，由于从库随时会切换为主库。以下：

set global read_only=1

二、配置三台机器之间的信任机制（省）

目的：机器之间可以无需输入密码进行访问。

三、安装mha软件

rpm安装：每台机器都要安装node，manager节点建议安装到单独的一台机器上或者一个不用切换为主的从库上

#安装可能须要的依赖包
[root@node1 software]# yum install perl-DBD-MySQL  
[root@node1 software]# yum install perl-Config-Tiny
[root@node1 software]# yum install perl-Parallel-ForkManager*.rpm                
[root@node1 software]# yum install perl-Mail-Sender*.rpm 
[root@node1 software]# yum install perl-Mail-Sendmail*.rpm 
[root@node1 software]# yum install perl-Log-Dispatch*.rpm 
#安装mha，这里用rpm包安装，默认在/usr/bin
[root@node1 software]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm
[root@node1 software]# yum install mha4mysql-manager-0.56-0.el6.noarch.rpm

二进制包安装

#node安装
wget http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.53.tar.gz
tar xf mha4mysql-node-0.53.tar.gz
cd mha4mysql-node-0.53
perl Makefile.PL
make && make install

#manager安装
wget http://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.53.tar.gz
tar xf mha4mysql-manager-0.53.tar.gz 
cd mha4mysql-manager-0.53
perl Makefile.PL
make && make install

四、手工配置主库服务器的vip并测试

这里经过脚本手动建立vip，以下：

[root@node1 scripts]# cat init_vip.sh 
vip="192.168.245.100/32"
/sbin/ip addr add $vip dev eth0

【测试】

绑定完成后，能够用如下命令查看绑定状况：

[root@node2 etc]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:d7:0f:4a brd ff:ff:ff:ff:ff:ff
    inet 192.168.245.131/24 brd 192.168.245.255 scope global eth0
    inet 192.168.245.100/32 scope global eth0
    inet6 fe80::20c:29ff:fed7:f4a/64 scope link 
       valid_lft forever preferred_lft forever

到任意从库ssh 192.168.245.100 --看是否连上vip或者mysql -h 192.168.245.100 -udarren -pdarren --是否连上vip数据库. 若是都可以链接上，表示vip设置成功了。

五、配置mha及启动

（1）建立mha监控用户（在主库执行，这样每一个服务器都有这个用户了）

mysql> grant all privileges on *.* to 'root'@'%' identified  by '123456';
Query OK, 0 rows affected (0.00 sec)

mysql> flush  privileges;
Query OK, 0 rows affected (0.01 sec)

（2）关闭purge_relay_logs：

在修改配置文件前，注意一个知识点，须将从库上的relay log自动清除设置为OFF，由于MySQL数据库主从复制在缺省状况下从库的relay logs会在SQL线程执行完毕后被自动删除，可是对于MHA场景下，对于某些滞后从库的恢复依赖于其余从库的relay log，所以采起禁用自动删除功能以及按期清理的办法。对于清理过多过大的relay log须要注意引发的复制延迟资源开销等。MHA可经过purge_relay_logs脚本及配合cronjob来完成此项任务。

purge_relay_logs的主要功能：

a、为relay日志建立硬连接(最小化批量删除大文件致使的性能问题)

b、SET GLOBAL relay_log_purge=1; FLUSH LOGS; SET GLOBAL relay_log_purge=0;
c、删除relay log（rm –f /path/to/archive_dir/*）

purge_relay_logs的用法及相关参数
1 purge_relay_logs --help
   Usage:
       purge_relay_logs --user=root --password=rootpass --host=127.0.0.1

2 参数描述
--user             用户名，缺省为root
--password         密码
--port             端口号
--host             主机名，缺省为127.0.0.1
--workdir          指定建立relay log的硬连接的位置，默认是/var/tmp，成功执行脚本后，硬连接的中继日志文件被删除,因为系统不一样分区建立硬连接文件会失败，故须要执行硬连接具体位置，建议指定为relay log相同的分区
--disable_relay_log_purge 默认状况下，若是参数relay_log_purge=1，脚本不作任何处理，自动退出.设定该参数，脚本会将relay_log_purge设置为0，当清理relay log以后，最后将参数设置为OFF(0)

3 定制清理relay log cronjob
pureg_relay_logs脚本在不阻塞SQL线程的状况下自动清理relay log。对于不断产生的relay log直接将该脚本部署到crontab以实现按天或按小时按期清理。
$ crontab -l 
# purge relay logs at 5am 
0 5 * * * app /usr/bin/purge_relay_logs --user=root --password=PASSWORD --disable_relay_log_purge >> /var/log/masterha/purge_relay_logs.log 2>&1

在咱们的两个从库上设置relaylog为OFF:

(product)root@127.0.0.1 [(none)]> set global relay_log_purge=0;
Query OK, 0 rows affected (0.00 sec)

而后经过定时任务，每隔一天定时清除relaylog：

#清除脚本
#!/bin/bash
user=root
passwd=root
port=3306
log_dir='/data/masterha/log'
work_dir='/data'
purge='/usr/bin/purge_relay_logs'

if [ ! -d $log_dir ]
then
   mkdir $log_dir -p
fi

$purge --user=$user --password=$passwd --disable_relay_log_purge --port=$port --workdir=$work_dir >> $log_dir/purge_relay_logs.log 2>&1

#定时任务
crontab -e
#天天早上5点10分执行
10 5 * * * sh /data/scripts/purge_relay_log.sh

（3）修改配置文件：

到manager节点的/etc下面新建masterha目录，并将mha须要的配置初始化文件拷贝到该目录下：

[root@node3 ~]# cd /etc
[root@node3 etc]# mkdir masterha
#建立如下mha日志目录，没有则报错
[root@node3 etc]#mkdir -p /var/log/masterha/app1

[root@node3 mastermha]# ll
total 32
-rw-r--r--. 1 root root   503 Nov  9 01:26 app1.conf
-rwxr-xr-x. 1 root root    55 Nov  9 01:26 drop_vip.sh
-rwxr-xr-x. 1 root root    55 Nov  9 01:26 init_vip.sh
-rw-r--r--. 1 root root   357 Nov  9 01:26 masterha_default.conf
-rwxr-xr-x. 1 root root  3888 Nov  9 01:26 master_ip_failover
-rwxr-xr-x. 1 root root 10298 Nov  9 01:26 master_ip_online_change

而后修改vip的值：在masterha目录下执行grep "vip" *,将会列出全部文件中vip变量，而后一一修改成192.168.245.100。

修改app1.conf文件：

[server default]
manager_log=/var/log/masterha/app1/app1.log
manager_workdir=/var/log/masterha/app1
master_ip_failover_script="/etc/masterha/master_ip_failover"
master_ip_online_change_script="/etc/masterha/master_ip_online_change"
password=root
ping_interval=1
remote_workdir=/var/log/masterha/app1
repl_password=repl4slave
repl_user=repl
report_script="/etc/masterha/send_mail"
shutdown_script=""
ssh_user=root
user=root

[server1]
candidate_master=1
check_repl_delay=0
hostname=192.168.245.129
master_binlog_dir=/data/mysql/mysql_3306/logs

[server3]
hostname=192.168.245.132
port=3306

（4）检查mha环境并启动

#检查MHA Manger到全部MHA Node的SSH链接状态：
[root@node3 masterha]# /usr/bin/masterha_check_ssh --conf=/etc/masterha/app1.conf
Mon Nov 16 01:24:21 2015 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Nov 16 01:24:21 2015 - [info] Reading application default configuration from /etc/masterha/app1.conf..
Mon Nov 16 01:24:21 2015 - [info] Reading server configuration from /etc/masterha/app1.conf..
Mon Nov 16 01:24:21 2015 - [info] Starting SSH connection tests..
Mon Nov 16 01:24:24 2015 - [debug] 
Mon Nov 16 01:24:21 2015 - [debug]  Connecting via SSH from root@192.168.245.129(192.168.245.129:22) to root@192.168.245.131(192.168.245.131:22)..
Mon Nov 16 01:24:23 2015 - [debug]   ok.
Mon Nov 16 01:24:23 2015 - [debug]  Connecting via SSH from root@192.168.245.129(192.168.245.129:22) to root@192.168.245.132(192.168.245.132:22)..
Mon Nov 16 01:24:24 2015 - [debug]   ok.
Mon Nov 16 01:24:25 2015 - [debug] 
Mon Nov 16 01:24:22 2015 - [debug]  Connecting via SSH from root@192.168.245.131(192.168.245.131:22) to root@192.168.245.129(192.168.245.129:22)..
Mon Nov 16 01:24:23 2015 - [debug]   ok.
Mon Nov 16 01:24:23 2015 - [debug]  Connecting via SSH from root@192.168.245.131(192.168.245.131:22) to root@192.168.245.132(192.168.245.132:22)..
Mon Nov 16 01:24:25 2015 - [debug]   ok.
Mon Nov 16 01:24:25 2015 - [debug] 
Mon Nov 16 01:24:22 2015 - [debug]  Connecting via SSH from root@192.168.245.132(192.168.245.132:22) to root@192.168.245.129(192.168.245.129:22)..
Mon Nov 16 01:24:24 2015 - [debug]   ok.
Mon Nov 16 01:24:24 2015 - [debug]  Connecting via SSH from root@192.168.245.132(192.168.245.132:22) to root@192.168.245.131(192.168.245.131:22)..
Mon Nov 16 01:24:25 2015 - [debug]   ok.
Mon Nov 16 01:24:25 2015 - [info] All SSH connection tests passed successfully.

View Code

若是遇到这个报错：

Can't exec "mysqlbinlog": No such file or directory at /usr/share/perl5/vendor_perl/MHA/BinlogManager.pm line 106.
mysqlbinlog version command failed with rc 1:0, please verify PATH, LD_LIBRARY_PATH, and client options
 at /usr/bin/apply_diff_relay_logs line 493
Mon Nov 16 01:32:36 2015 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln205] Slaves settings check failed!
Mon Nov 16 01:32:36 2015 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln413] Slave configuration failed.
Mon Nov 16 01:32:36 2015 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations.  at /usr/bin/masterha_check_repl line 48
Mon Nov 16 01:32:36 2015 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers.
Mon Nov 16 01:32:36 2015 - [info] Got exit code 1 (Not master dead).

MySQL Replication Health is NOT OK!

解决方法以下，添加软链接（全部节点）

ln -s /usr/local/mysql/bin/mysqlbinlog /usr/local/bin/mysqlbinlog

ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql

到此为止，都没问题了，开始启动manager节点进行监控，通常启动咱们都使用nohup方式，可是当出现故障成功切换后，manager监控也会关闭，因此建议使用daemontools方式在后台运行。

nohup方式启动

nohup /usr/bin/masterha_manager --conf=/etc/masterha/app1.conf --remove_dead_master_conf --ignore_last_failover &
#关闭mha监控
/usr/bin/masterha_stop --conf=/etc/masterha/app1.conf

daemontools方式启动：

#下载daemontools工具
wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
#安装
cd /home/software/daemontools/admin/daemontools-0.76
vim src/conf-cc #在第一行最后空一格后添加 -include /usr/include/errno.h 避免编译时报错
package/install  #安装
#在/etc/init/建立svscan.conf文件并添加以下内容：
vim /etc/init/svscan.conf
start on runlevel [345]
        respawn
        exec /command/svscanboot
#在/etc/init目录下从新加载并启动
[root@node3 init]# initctl reload-configuration
[root@node3 init]# initctl start svscan
svscan start/running, process 17002

使用daemon启动mha监控：

[root@node3 init]# mkdir -p /service/masterha_app
[root@node3 ~]# cd /service/masterha_app/
[root@node3 masterha_app]# pwd
/service/masterha_app
#在/service/masterha_app/建立run脚本并增长执行权限，内容以下
[root@node3 masterha_app]# cat /service/masterha_app/run
#!/bin/bash
 exec /usr/bin/masterha_manager --conf=/etc/masterha/app1.conf --remove_dead_master_conf --ignore_last_failover
[root@node3 masterha_app]# chmod +x /service/masterha_app/run
#中止监控 
svc -d /service/masterha_app 
#开启监控 
svc -u /service/masterha_app

另起一个session，查看启动日志：

[root@node3 app1]# tail -f app1.log 
192.168.245.129(192.168.245.129:3306) (current master)
 +--192.168.245.131(192.168.245.131:3306)
 +--192.168.245.132(192.168.245.132:3306)

Mon Nov 16 01:55:10 2015 - [warning] master_ip_failover_script is not defined.
Mon Nov 16 01:55:10 2015 - [warning] shutdown_script is not defined.
Mon Nov 16 01:55:10 2015 - [info] Set master ping interval 1 seconds.
Mon Nov 16 01:55:10 2015 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Mon Nov 16 01:55:10 2015 - [info] Starting ping health check on 192.168.245.129(192.168.245.129:3306)..
Mon Nov 16 01:55:10 2015 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..

当看到最后一句“Ping(SELECT) succeeded, waiting until MySQL doesn't respond..”表示mha已经启动起来了。固然，你或许在一台机子上但愿监控多套master-salve复制，这很是容易，只要为第二套集群建立一个新的配置文件并启动manager

1	`# masterha_manager` `--conf=/etc/conf/masterha/app1.cnf <br># masterha_manager --conf=/etc/conf/masterha/app2.cnf<br>若是你在app1和app2上有一些共有的参数，可在全局配置文件中配置。`

启动参数介绍：

--remove_dead_master_conf 该参数表示当发生主从切换后，老的主库的ip将会从配置文件中移除。若是故障机器修复好了，须要手工添加ip信息到配置文件中

--manger_log 日志存放位置

--ignore_last_failover 在缺省状况下，若是MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之因此这样限制是为了不ping-pong效应。该参数表明忽略上次MHA触发切换产生的文件，默认状况下，MHA发生切换后会在日志目录，也就是上面我设置的/data产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不容许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为--ignore_last_failover。

查看MHA Manager监控是否正常：

[root@node3 app1]#  /usr/bin/masterha_check_status --conf=/etc/masterha/app1.conf
app1 (pid:6795) is running(0:PING_OK), master:192.168.245.129

六、模拟测试

（1）自动Failover测试

首先用sysbench工具模拟主库业务的写入。

#下载sysbench
http://dev.mysql.com/downloads/benchmarks.html
#安装sysbench
yum install libtool -y  #依赖包
tar zxvf sysbench-0.4.12.7.tar.gz
cd sysbench-0.4.12.7
./configure && make && make install

在主库执行，建立sysbench测试表：

(product)root@127.0.0.1 [(none)]> create database sbtest;
Query OK, 1 row affected (0.00 sec)

[root@node1 sysbench-0.4.12.7]# /usr/local/bin/sysbench --test=oltp --oltp-table-size=100000 --oltp-read-only=off --init-rng=on --num-threads=4 --max-requests=0 --oltp-dist-type=uniform --max-time=1800 --mysql-user=root --mysql-socket=/tmp/mysql_3306.sock --mysql-password=root --mysql-host=192.168.245.129 --db-driver=mysql --mysql-table-engine=innodb --oltp-test-mode=complex prepare
sysbench 0.4.12.6:  multi-threaded system evaluation benchmark

Creating table 'sbtest'...
Creating 100000 records in table 'sbtest'...

中止接管主库那个从库的io_thread线程：

(product)root@127.0.0.1 [(none)]> stop slave io_thread;
Query OK, 0 rows affected (0.01 sec)

向主库插入数据：

[root@node1 sysbench-0.4.12.7]# /usr/local/bin/sysbench --test=oltp --oltp-table-size=100000 --oltp-read-only=off --init-rng=on --num-threads=4 --max-requests=0 --oltp-dist-type=uniform --max-time=180 --mysql-user=root --mysql-socket=/tmp/mysql_3306.sock --mysql-password=root --mysql-host=192.168.245.129 --db-driver=mysql --mysql-table-engine=innodb --oltp-test-mode=complex run
sysbench 0.4.12.6:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4
Initializing random number generator from timer.

Random number generator seed is 0 and will be ignored


Doing OLTP test.
Running mixed OLTP test
Using Uniform distribution
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Using 1 test tables
Threads started!
Time limit exceeded, exiting...
(last message repeated 3 times)
Done.

OLTP test statistics:
    queries performed:
        read:                            489090
        write:                           174675
        other:                           69870
        total:                           733635
    transactions:                        34935  (194.05 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 663765 (3686.93 per sec.)
    other operations:                    69870  (388.10 per sec.)

Test execution summary:
    total time:                          180.0317s
    total number of events:              34935
    total time taken by event execution: 719.7722
    per-request statistics:
         min:                                  3.47ms
         avg:                                 20.60ms
         max:                                444.43ms
         approx.  95 percentile:              28.17ms

Threads fairness:
    events (avg/stddev):           8733.7500/260.92
    execution time (avg/stddev):   179.9430/0.01

而后启动从库上io_thread:

(product)root@127.0.0.1 [(none)]> start slave io_thread;
Query OK, 0 rows affected, 1 warning (0.00 sec)

kill主库的mysqld：

pkill -9 mysqld

最后，查看mha日志，这时已经接管过来了！

View Code)

（2）修复故障master

一般状况下自动切换之后，待原master主机修复后，若是数据完整的状况下，可能想把原来master从新做为新主库的slave，这时咱们能够借助当时自动切换时刻的MHA日志来完成对原master的修复。下面是提取相关日志的命令：

[root@node3 masterha]#  grep -i "All other slaves should start" /var/log/masterha/app1/app1.log
Mon Nov 16 03:02:20 2015 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='192.168.245.131', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000013', MASTER_LOG_POS=35416929, MASTER_USER='repl', MASTER_PASSWORD='xxx';

将change master to拿到原master上执行，那么就做为新master的slave了。

（3）在线切换测试

在许多状况下，须要将现有的主服务器迁移到另一台服务器上。好比主服务器硬件故障，RAID 控制卡须要重建，将主服务器移到性能更好的服务器上等等。 MHA 提供快速切换和优雅的阻塞写入，这个切换过程只须要 0.5-2s 的时间，这段时间内数据是没法写入的。在不少状况下，0.5-2s 的阻塞写入是能够接受的。所以切换主服务器不须要计划分配维护时间窗口。

MHA在线切换的大概过程：
1.检测复制设置和肯定当前主服务器
2.肯定新的主服务器
3.阻塞写入到当前主服务器
4.等待全部从服务器遇上复制
5.授予写入到新的主服务器
6.从新设置从服务器

注意，在线切换的时候应用架构须要考虑如下两个问题：

1.自动识别master和slave的问题（master的机器可能会切换），若是采用了vip的方式，基本能够解决这个问题。

2.负载均衡的问题（能够定义大概的读写比例，每台机器可承担的负载比例，当有机器离开集群时，须要考虑这个问题）

为了保证数据彻底一致性，在最快的时间内完成切换，MHA的在线切换必须知足如下条件才会切换成功，不然会切换失败。

1.全部slave的IO线程都在运行

2.全部slave的SQL线程都在运行

3.全部的show slave status的输出中Seconds_Behind_Master参数小于或者等于running_updates_limit秒，若是在切换过程当中不指定running_updates_limit,那么默认状况下running_updates_limit为1秒。

4.在master端，经过show processlist输出，没有一个更新花费的时间大于running_updates_limit秒。

在线切换步骤以下：

首先，停掉MHA监控：

[root@node3 app1]# svc -d /service/masterha_app
[root@node3 app1]# checkstatus 
app1 is stopped(2:NOT_RUNNING).

其次，进行在线切换操做（模拟在线切换主库操做，原主库192.168.245.129变为slave，192.168.245.131提高为新的主库）

[root@node3 masterha]# /usr/bin/masterha_master_switch --conf=/etc/masterha/app1.conf --master_state=alive --new_master_host=192.168.245.131 --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=10000
Mon Nov 16 21:47:24 2015 - [info] MHA::MasterRotate version 0.56.
Mon Nov 16 21:47:24 2015 - [info] Starting online master switch..
Mon Nov 16 21:47:24 2015 - [info] 
Mon Nov 16 21:47:24 2015 - [info] * Phase 1: Configuration Check Phase..
Mon Nov 16 21:47:24 2015 - [info] 
Mon Nov 16 21:47:24 2015 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Nov 16 21:47:24 2015 - [info] Reading application default configuration from /etc/masterha/app1.conf..
Mon Nov 16 21:47:24 2015 - [info] Reading server configuration from /etc/masterha/app1.conf..
Mon Nov 16 21:47:24 2015 - [info] GTID failover mode = 0
Mon Nov 16 21:47:24 2015 - [info] Current Alive Master: 192.168.245.129(192.168.245.129:3306)
Mon Nov 16 21:47:24 2015 - [info] Alive Slaves:
Mon Nov 16 21:47:24 2015 - [info]   192.168.245.132(192.168.245.132:3306)  Version=5.6.21-log (oldest major version between slaves) log-bin:enabled
Mon Nov 16 21:47:24 2015 - [info]     Replicating from 192.168.245.129(192.168.245.129:3306)

It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 192.168.245.129(192.168.245.129:3306)? (YES/no): yes
Mon Nov 16 21:47:35 2015 - [info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long time..
Mon Nov 16 21:47:35 2015 - [info]  ok.
Mon Nov 16 21:47:35 2015 - [info] Checking MHA is not monitoring or doing failover..
Mon Nov 16 21:47:35 2015 - [info] Checking replication health on 192.168.245.132..
Mon Nov 16 21:47:35 2015 - [info]  ok.
Mon Nov 16 21:47:35 2015 - [error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln1218] 192.168.245.131 is not alive!
Mon Nov 16 21:47:35 2015 - [error][/usr/share/perl5/vendor_perl/MHA/MasterRotate.pm, ln232] Failed to get new master!
Mon Nov 16 21:47:35 2015 - [error][/usr/share/perl5/vendor_perl/MHA/ManagerUtil.pm, ln177] Got ERROR:  at /usr/bin/masterha_master_switch line 53

这里怎么会报错呢？意思是131这个机器not alive，但是我去检查下没有问题啊，主从也ok的，后来发现了问题所在，缘由是：以前启动的manager脚本中加上了--remove_dead_master_conf参数，致使appl.conf中没有131机器的配置。

而后到app1.conf中加上131机器的配置信息，再次执行：

View Code

其中参数的意思：

--orig_master_is_new_slave 切换时加上此参数是将原 master 变为 slave 节点，若是不加此参数，原来的 master 将不启动

--running_updates_limit=10000,故障切换时,候选master 若是有延迟的话， mha 切换不能成功，加上此参数表示延迟在此时间范围内均可切换（单位为s），可是切换的时间长短是由recover 时relay 日志的大小决定

（4）切换时发送邮件：

须要建立一个send_mail脚本，而后将脚本路径写入app1.conf中便可。

View Code

至此，mysql mha部分就搞定了，下面将会结合mha这个架构加入代理层，从而实现读写分离功能，主要采用360公司的Atlas，敬请期待。。。