33.高可用架构
33.1 MMM架构
MMM(Master-Master replication manager for MySQL)是一套支持双主故障切换和双主日常管理的脚本程序(Perl)。
主要用来监控和管理MySQL Master-Master双主复制。
优点：故障切换、多个Slave的read负载均衡。
缺点：无法完全保证数据一致性。

33.2 MHA架构
MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案。
MHA由DeNA公司youshimaton(现就职于facebook)开发。
MHA的功能是MySQL高可用环境的的故障切换、主从提升。
MHA能做到0~30秒内完成故障切换，最大程度的保证数据的一致性。
MHA有管理节点(MHA Manager)和数据节点(MHA Node)两部分组成。
MHA Manager可以管理一个或多个MySQL集群，可以单独部署在一台服务器上，或者部署在slave所在的服务器上。
MHA Node部署在每台MySQL数据库上。
限制：
MySQL集群最小规模为一主两从。
MHA Manager不能部署在Master上。
故障前日志的差异：
master上binlog日志》最新更新的slave的relay log》非最新更新的slave的relay log
master上binlog日志中未同步到最新从库的binlog event称为主与从之间数据差异。
最新从库与非最新从库之间relay log的差异称为从与从之间数据差异。
MHA的主要功能：
通过MHA Manager管理调度MHA Node，MHA Node负责通过ssh来复制主与从之间数据差异和从与从之间数据差异；
将差异数据应用给最新的Master，从而保证数据的一致性。
MHA故障切换过程：
1.识别含有最新更新的slave；
2.从宕机崩溃的Master保存主从间差异binlog event；前提是MHA Manager可以通过ssh连接Master。
3.应用差异的中继日志(relay log)到其它slave；保证各个slave都更新到最新。
4.应用从master保存的binlog event。
5.提升slave(Candicate master)为新的master。
6.将其它slave连接到新的master进行复制。
Manager工具包：
masterha_manager 启动MHA
masterha_stop 停止MHA
masterha_check_status 检查MHA的运行状态
masterha_check_ssh 检查MHA的ssh配置状况
masterha_check_repl 检查MHA的复制状况，查看主、从复制的状态，show master/slave status;
masterha_master_monitor 监控master是否宕机
masterha_master_switch 故障切换(手动或自动)
masterha_conf_host 配置server信息
masterha_secondary_check 第二次检查
Node工具包(由Manager调用，无需手动操作)：
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件，并将差异的事件应用于其它slave。
purge_relay_logs 清除中继日志(不会阻塞SQL线程)
filter_mysqlbinlog 过滤不必要的binlog日志，即过滤rollback事件(MHA不再使用该工具)。
Master宕机崩溃后，如果Manager不能通过ssh连接Master，将导致主与从之间数据差异部分丢失。
为解决该问题可以考虑启用MySQL半同步复制。
复制有三个线程：binlogdump线程、I/O线程、SQL线程，三个线程是异步时称为异步复制，三个线程都同步时称为同步复制(没有该解决方案)。
半同步复制指复制的binlog dump线程和I/O线程是同步的，SQL线程是独立的。
主库执行完commit操作，且主库写入binlog日志，等待一个从库也接收到binlog并成功写入中继日志后，最终成功返回客户端。
半同步复制事务提交需要等待binlog传递到从库并写入relay log后，再由从库通知主库收到binlog，才能完成。
往返时延(RTT)指从发送端发送数据到发送端收到接收端的确认，总共经历的时长。
半同步复制性能取决与主、从之间的往返时延。

33.3 安装部署MHA
环境准备：
角色 IP地址 主机名 Server ID 类型
Master 192.168.7.81 db1 1 写入
Candicate Master 192.168.7.82 db2 2 读取
Slave 192.168.7.83 db3 3 读取
Monitor host 192.168.7.84 mah 监控集群组
VIP 192.168.7.80
33.3.1 安装MAH node（在所有节点上安装）
1.安装perl模块(BDB::mysql),MHA Node依赖perl
install.sh如下：
#!/bin/bash
wget http://xrl.us/cpanm --no-check-certificate #下载步骤需要网络
mv cpanm /usr/bin #移动
chmod 755 usr/bin/cpanm #授权
cat >/root/list<<EOF
install BDB::mysql #安装
EOF
for package in `cat /root/list` #循环
do
cpanm $package
done
2.安装MHA node
wget http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.53.tar.gz #下载步骤需要网络
tar xvzf mha4mysql-node-0.53.tar.gz
cd mha4mysql-node-0.53
perl Makefile.PL
make #源码编译
make install #安装
安装后会在/usr/bin/下生成Node工具包脚本。

33.3.2 安装MHA Manager
MHA Manager节点也需要安装perl模块(BDB::mysql)和MHA node。
1.安装MHA Manager所需的perl模块
install.sh如下：
#!/bin/bash
wget http://xrl.us/cpanm --no-check-certificate #下载步骤需要网络
mv cpanm /usr/bin #移动
chmod 755 usr/bin/cpanm #授权
cat >/root/list<<EOF
install BDB::mysql #安装
install Config::Tiny
install Log::Dispatch
install Parallel::ForkManager
install Time::HiRes
EOF
for package in `cat /root/list` #循环
do
cpanm $package
done
2.安装MHA Manager
wget http://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.53.tar.gz #下载步骤需要网络
tar -zxf mha4mysql-manager-0.53.tar.gz
cd mha4mysql-manager-0.53
perl Makefile.PL
make #源码编译
make install #安装
安装后会在/usr/bin/下生成Manager工具包脚本。

33.3.3 配置SSH登录无密码验证
1.在Manager上配置到所有节点的无密码验证：
ssh-kengen -t rsa
ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.7.81
ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.7.82
ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.7.83
2.分别在每台MySQL节点上配置到另外两台MySQL节点的无密码验证：
如在Master上配置到Candicate Master和Slave的无密码验证
ssh-kengen -t rsa
ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.7.82
ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.7.83

33.3.4 搭建主从复制环境
1.在Master上执行备份
$mysqldump --master-data=2 --single-transaction --default-character-set=gbk -R --triggres -A>backup.sql
说明：
--master-data=2指备份时刻记录master的binlog文件名和位置
--single-transaction指单个事务，获取一致性快照
-R指备份存储过程和函数
--triggres指备份触发器
-A指备份所有schema
2.在Master上创建复制用户
mysql>create user 'repl'@'192.168.7.%' indentified by 'repl';
mysql>grant replication slave on *.* to 'repl'@'192.168.7.%';
3.查看Master上备份时刻的binlog的文件名和位置
mysql>show master status;
# head -n 30 backup.sql | grep -i "CHANGE MASTER TO"
4.将备份文件复制到Candicate Master和Slave
# scp backup.sql db2:/home/mysql/
# scp backup.sql db3:/home/mysql/
5.在Candicate Master上导入数据，被将复制指向Master及查看复制状态
# mysql -f -default-character-set=gbk < backup.sql
# mysql -S /tmp/mysql_3307.sock
mysql>change master to master_host='master的IP',master_port='master的port',master_user='复制用户',master_password='复制用户密码',master_log_file='复制文件',master_log_pos=复制位置;
mysql>start slave;
mysql>show slave status;
当Candicate Master上复制的I/O线程和SQL线程状态正常即成功。
6.在Slave上导入数据，被将复制指向Master及查看复制状态
# mysql -f -default-character-set=gbk < backup.sql
# mysql -S /tmp/mysql_3307.sock
mysql>change master to master_host='master的IP',master_port='master的port',master_user='复制用户',master_password='复制用户密码',master_log_file='复制文件',master_log_pos=复制位置;
mysql>start slave;
mysql>show slave status;
当Slave上复制的I/O线程和SQL线程状态正常即成功。
7.设置Candicate Master和Slave为read only
#mysql -e "set global read_only=1;"
mysql>set global read_only=1; #从库对外只提供读服务
8.在Master上为Manager创建监控用户并授权
mysql>create user 'monitor'@'192.168.7.%' indentified by 'monitor';
mysql>grant all privileges on *.* to 'monitor'@'192.168.7.%';

33.3.5 配置MHA
1.创建MHA配置文件
#mkdir -p /etc/masterha/ #创建目录
#vi /etc/masterha/app1.cnf #创建配置文件
[server default]
manager_workdir=/etc/masterha/app1 #设置manager的工作目录
manager_log=/etc/masterha/app1/app1.log #设置manager的日志
master_binlog_dir=/data/mysql/ #设置master的binlog的目录
master_ip_failover_script=/usr/local/bin/master_ip_failover #设置自动failover时的切换脚本
master_ip_online_change_script=/usr/local/bin/master_ip_online_change #设置手动切换时的切换脚本
password=root #设置MySQL数据库中root账户的密码
ping_interval=1 #设置监控主库，发送ping包的时间间隔(默认为3s)，尝试3次没有回应时自动failover
remote_workdir=/tmp #设置远端mysql在发生切换时binlog的保存位置
repl_user=repl #设置复制用户的用户名
repl_password=repl #设置复制用户的密码
report_script=/usr/local/bin/send_report #设置发生切换后发送报警的脚本
secondary_check_script=/usr/bin/masterha_secondary_check -s db2 -s db1 --user=root --master_host=db1 --master_ip=192.168.7.81 --master_port=3306
#Manager发现到master的网络故障时，会尝试从candicate master来登录master
shutdown_script="" #设置故障发生后关闭故障主机脚本
ssh_user=root #设置ssh的登录用户名
user=monitor #设置监控用户的用户名

[servver1]
hostname=192.168.7.81 #Master库IP
port=3306
[servver2]
hostname=192.168.7.82 #备用Master库IP
port=3306
candicate_master=1 #将db2设置为备用Master，发生主从切换后，会将db2提升为主库，即使这个库不是集群中最新的slave
check_repl_delay=0 #忽略备用Master的复制延迟，保证备用Master在主从切换后一定是新的Master。
#默认slave落后master100M的relay log时，发生主从切换时将不会被选做新的master(即时这个slave被设置为备选master)。
#candicate_master=1和check_repl_delay=0联合使用可以确定发生主从切换后，会将db2提升为主库，即使db2落后slave也落后master100M以上。
hostname=192.168.7.83 #Slave库IP
port=3306
2.在Candicate Master和Slave上设置relay log清除方式
mysql>mysql -e "set global relay_log_purge=0";
mysql>set global relay_log_purge=0;
默认情况下，从库上relay log会SQL线程执行完成后自动删除，
但时，MHA发生切换时，从从差异需要依赖relay log来恢复，所以需要禁止relay log的自动清除，改为定期清除。
在ext3文件系统下，删除大文件需要一定的时间，会导致严重的复制延时。
所以，定期清除relay log时，需要为relay log创建硬连接，再通过删除硬连接来删除relay log。
Node工具包的purge_relay_logs命令即采用删除硬连接方式来删除relay log。
purge_relay_logs命令例子：
#/usr/bin/purge_relay_logs --host=localhost --port=3306 --user=root --password=root -disable_relay_log_purge --workdir=/data/mysql/
参数说明：
--host=localhost 数据库地址
--port=3306 数据库端口号
--user=root 数据库root账户
--password=root 数据库root账户密码
--workdir=/data/ln/ 指定创建relay log的硬连接的位置，默认为/var/tmp,需要与relay log文件在同一个系统分区。脚本成功执行后，硬连接的中继日志文件将被删除。
-disable_relay_log_purge 如果参数relay_log_purge=1(由MySQL自动删除relay log)，则脚本直接自动退出。
如果参数relay_log_purge=0(MySQL不自动删除relay log)，则脚本先找到relay-log.info文件(索引)，通过该索引文件找到过期的relay log,
给过期的relay log创建硬连接，再通过设置参数relay_log_purge=1调用MySQL删除relay log的功能来删除过期relay log的硬连接，
最后设置参数relay_log_purge=0关闭MySQL删除relay log功能。
3.设置定期清理relay脚本
通过Linux定时任务(crontab)定期清理relay log。
vi /etc/cron.d/purge_relay_logs
0 4 * * * /usr/bin/purge_relay_logs --user=root --password=root -disable_relay_log_purge --port=3306 --workdir=/home/mysqlhome -disable_relay_log_purge>>/usr/local/masterha/log/purge_relay_logs.log 2>&1
purge_relay_logs脚本每4分钟删除一次relay log，删除过程不阻塞SQL线程。
在每台slave服务器不同时间点设置该定时任务。

4.在Candicate Master和Slave上设置mysqlbinlog命令的环境变量
MHA在切换时需要调用mysqlbinlog命令来读取主库binlog和从库relay log，所以需要在环境变量中指定mysqlbinlog命令的具体路径。
编辑/etc/bashrc文件，在文件末尾处增加：
PATH="$PATH:/home/mysql/mysqlhome/bin"
export PATH

33.3.6 检查SSH的配置
使用masterha_check_ssh工具脚本检查MHA Manager到所有MHA Node的SSH连接状态：
# masterha_check_ssh --conf=/etc/masterha/app1.cnf
说明：
masterha_check_ssh工具脚本读取配置文件/etc/masterha/app1.cnf中服务器的信息，
再通过类似于telnet的网络命令来检查各节点的ssh服务是否正常。

33.3.7 检查整个复制环境状况
使用masterha_check_repl工具脚本检查Candicate Master和Slave节点的MySQL复制状态
# masterha_check_repl --conf=/etc/masterha/app1.cnf
说明：
masterha_check_repl工具脚本读取配置文件/etc/masterha/app1.cnf中服务器的信息，
识别Master节点、Candicate Master节点、Slave节点，再检查Master节点和Slave节点的show slave status。
0.53版本的错误和解决方法：
ERROR:Use of uninitialized value in scalar chomp at /usr/lib/perl5/site_perl/5.8.8/MHA/ManagerConst.pm line 90
在ManagerConst.pm的90行添加$msg="" unless($msg)

33.3.8 检查MHA Manager的状态
使用masterha_check_status工具脚本检查MHA Manager的状态
# masterha_check_status --conf=/etc/masterha/app1.cnf
输出结果说明：
INITIALIZING_MONITOR：指初始化MHA Manager监控，10s后将转为PING_OK。
PING_OK：指MHA Manager的状态正常
NOT_RUNNING：指MHA Manager的状态未启动，解决方法是开启MHA Manager监控。
FAILOVER_RUNNING：指master故障，MHA Manager的状态是正在故障切换中。
PING_FAILING：指Manager到Master之间的网络故障。

33.3.9 开启MHA Manager监控
使用masterha_manager工具脚本启动MHA Manager
# nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover</dev/null >/masterha/app1/manager.log 2>&1 &
参数说明：
--conf=/etc/masterha/app1.cnf 指定配置文件
--remove_dead_master_conf 在发生切换后，故障master的配置信息(IP)将被从配置文件移除
--ignore_last_failover 忽略上次自动切换，即每次master故障时都会自动切换
默认情况下，第一次宕机发生自动切换，在不足8小时内发生第二次宕机将不会自动切换。
MHA发生自动切换后会在/masterha/app1/下产生app1.failover.complete文件，如果不手动删除该文件(rm -f /masterha/app1/app1.failover.complete)，将导致后续master故障时不会自动切换。
>/masterha/app1/manager.log 指定启动日志文件位置
检查MHA Manager的状态：
# masterha_check_status --conf=/etc/masterha/app1.cnf
输出结果为INITIALIZING_MONITOR，10s后将转为PING_OK。

33.3.10 查看启动日志
使用tail命令查看启动过程的日志输出信息：
# tail /masterha/app1/app1.log
Ping(SELECT) succeeded 说明整个系统监控已经开始。

33.3.11 关闭MHA Manager监控
使用masterha_stop工具脚本关闭MHA Manager监控
# masterha_stop --conf=/etc/masterha/app1.cnf
输出Stopped app1 successfully.

33.3.12 VIP配置
VIP配置方式分为两种：通过keepalived管理VIP，通过/usr/local/bin/master_ip_failover脚本管理VIP。
1.keepalived方式管理VIP
1.1 下载、安装keepalived
wget http://www.keepalived.org/software/keepalived-1.2.1.tar.gz
tar zxvf keepalived-1.2.1.tar.gz
cd keepalived-1.2.1
./configure --prefix=/usr/local/keepalived
--with-kernel-dir=/usr/src/kernels/2.6.18-164.el5-i686/
make && make install
cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/rc.d/init.d/
cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
mkdir /etc/keepalived
cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/
cp /usr/local/keepalived/sbin/keepalived/ /usr/sbin/
1.2 配置keepalived的配置文件keepalived.conf
在master上配置keepalived.conf(status backup,nopreempt,priority 150)；
在Candicate Master上配置keepalived.conf(status backup,nopreempt,priority 120)。
1.3 启动keepalived服务
# service keepalived start
1.4 查看IP地址绑定
# ip addr
VIP已经被绑定到master的eth0网卡上。
查看keepalived输出信息：
# tail -f /var/log/messages
1.5 keepalived的两种模式
master-->backup模式：master故障时，VIP漂移到slave；master修复后且启动keepalived时，VIP从slave被抢占到master，此时设置nopreempt无效。
backup-->backup模式：master故障时，VIP漂移到slave；master修复后且启动keepalived时，在设置nopreempt时，VIP不会从slave被抢占到master。优先级priority在backup-->backup模式下用来区分master和slave。
keepalived脑裂问题：当master和slave之间网络故障时，master仍持有VIP，salve失去与master的联系后，误认为master故障，也让VIP与eth0网卡绑定，持有VIP，造成IP冲突。
主从节点间网络不好时不要使用keepalived。
1.6 在MHA中引入keepaalived
在切换触发脚本master_ip_failover中添加对keepalived的处理。
vi /usr/local/bin/master_ip_failover
功能：当master故障时，会触发MHA切换，master_ip_failover调用keepalived的命令停止master上的keepalived服务，从而触发VIP漂移到slave。
$cmd='ssh '.$ssh_user.'@'.$orig_master_ip.' \'./lvs-admin stop\'';
lvs-admin实在master上的keepalived的启停脚本。
2.脚本方式管理VIP
在切换触发脚本master_ip_failover中处理。
参数定义
my $vip = '192.168.7.80'; #VIP
my $key = "2";
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";
启动VIP函数定义
sub start_ip(){
`ssh $ssh_user\@$new_master_host \" $ssh_start_vip\"`;
}
停止VIP函数定义
sub stop_ip(){
`ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip\"`;
}
在stop命令的eval模块调用stop_ip函数：
eval{
print "Disabling the VIP on old master - $orig_master_host \n";
&stop_ip();
$exit_code = 0;
}
在start命令的eval模块调用start_ip函数：
eval{
print "Enabling the VIP - $vip on the new master - $new_master_host \n";
&start_ip();
$exit_code = 0;
}

33.3.13 自动Failover
自动Failover模拟测试操作步骤：
1.sysbench生产测试数据
在master上通过sysbench给sbtest.sbtest表生成100万条测试数据
# sysbench --test=oltp --oltp-table-size=1000000 --oltp-read-only=off --init-rng=on --num-threads=16 --max-requests=0 --oltp-dist-type=uniform --max-time=1800 --mysql-user=root --db-driver=mysql --mysql-table-engine=innodb --oltp-test-mode=complex prepare
参数说明：
2.停止Candicate Master上的io线程，模拟主从延时。
mysql>stop slave io_thread;
slave上IO线程正常。
3.模拟sysbench压力测试
在master上进行sysbench测试，运行3分钟(180s)，产生大量binlog。
# sysbench --test=oltp --oltp-table-size=1000000 --oltp-read-only=off --init-rng=on --num-threads=16 --max-requests=0 --oltp-dist-type=uniform --max-time=180 --mysql-user=root --db-driver=mysql --mysql-table-engine=innodb --oltp-test-mode=complex run
4.开启Candicate Master上的io线程,复制master的binlog。
mysql>start slave io_thread;
5.杀掉master上的mysql进程，模拟master故障，自动failover操作。
# ps axu|grep mysql_3306|awk '{print $2}'|xargs kill -9
6.在切换过程中查看MHA Manager的状态
# masterha_check_status --conf=/etc/masterha/app1.cnf
输出结果FAILOVER_RUNNING说明：master故障正在切换中。
7.在Manager上查看MHA切换日志
# tail -f /masterha/app1/app1.log
从Manager去连接master的Mysql，连续失败3次；
再从Manager去连接master的SSH，SSH可达；
读取配置文件/etc/masterha/app1.cnf,检查所有server的状态发现master死，备份master和slave活；
坚查slave配置；
检查复制的过滤条件；
关闭master；
开启故障切换：
第一阶段：检查配置
读取配置文件，检查各MySQL状态；
Master 死，备份Master 活，Slave 活。
第一阶段结束。
第二阶段：关闭Master
通过脚本master_ip_failover 取消VIP与Master网卡的绑定；
通过脚本shutdown_script 关闭Master，未配置该脚本时跳过。
第二阶段结束。
第三阶段：Master恢复
3.1 获取最新的slave，通过binlog文件名和位置来判断。
3.2 保存原master的binlog,通过save_binary_logs工具获取。
save_binary_logs --command=save --start_file=最新的binlog文件名 --start_pos=最新的binlog文件内位置 --binlog_dir=binlog文件目录
--output_file=保存后输出文件的目录和文件名 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.53
合并binlog(concat)，再拷贝到Manager本地(scp from root:MasterIP:/tmp/xxx.binlog to local:/masterha/app1/xxx.binlog)
3.3 确定新的master
从最新的slave处将所有rlay log复制到其它slave上，保证所有的slave上relay log同步。
有Candicate Master时选择Candicate Master为新master；没有Candicate Master时选择之前最新的slave为新master。
3.4 新master的日志差异处理
新master已经从最新的slave处获取了relay log文件,不需要再从最新的slave处获取其它文件。
从Manager上将原master的差异binlog文件xxx.binlog拷贝给新master（scp）。
注意：本阶段出现任何错误时都需要手动恢复
应用获取的最新relay log文件，直到exec_master_log_pos与read_master_log_pos相同。
应用原master的差异binlog:
apply_diff_relay_logs --command=apply --slave_user=root --slave_host=新masterIP --slave_ip=新masterIP --slave_port=3306
--apply_files=/tmp/xxx.binlog --workdir=/tmp --target_version=5.5.28-rel29.1-log --timestamp=xxx
--handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.53 --slave_pass=xxx
获取新master的binlog文件和位置；
其它Slave将复制指向新的master(change master to ...)；
通过master_ip_failover脚本在新master上绑定VIP；
取消新master的read_only的设置(set global read_only=0)；
第三阶段结束。
第四阶段：所有Slave恢复
所有Slave先恢复差异的relay log；
从Manager上将原master的差异binlog文件xxx.binlog拷贝给所有slave。
在所有Slave上引用差异的binlog。
将复制指向新的master，并重启复制。
第四阶段结束。
第五阶段：新Master清理
从新设置从节点信息；
在配置文件app1中删除原master信息。
第五阶段结束。
8.MHA切换过程总结：
配置文件检查阶段，这个阶段会检查整个集群配置文件设置；
宕机的master处理，这个阶段包括VIP摘除操作，主机关机等操作；
复制dead master和最新slave相差的relay log，并保存到MHA Manager具体目录下；
识别含有最新更新的slave；
应用差异的中继日志(relay log)到其它slave；
应用从master保存的二进制日志事件(binlog event)；
提升一个slave为新的master；
使其他slave连接新的master进行复制。

33.3.14 网络问题触发的Failover操作
Master网络故障，Manager和备份Master不能连接Master时不会发生自动Failover，只是反复尝试连接，并提示检查网络。
网络故障时MHA不会进行切换或误切换,需人工介入。
在master上设置防火墙，阻断Manager和备份Master的通信，模拟Master网络故障。
# iptables -A INPUT -s 192.168.7.84 -j DROP;
# iptables -A INPUT -s 192.168.7.82 -j DROP;
在Manager上查看MHA切换日志
# tail -f /masterha/app1/app1.log
检查MHA Manager的状态：
# masterha_check_status --conf=/etc/masterha/app1.cnf
输出结果PING_FAILING，人工介入检查，并决定是否需要手动切换。

33.3.15 手动Failover
手动Failover应用与没有启用MHA自动切换功能或MHA不能自动切换的场景。
使用masterha_master_switch工具脚本来手动Failover：
# masterha_master_switch --master_state=dead --conf=/etc/masterha/app1.cnf
--dead_master_host=masterIP --dead_master_port=3306
--new_master_host=新masterIP --new_master_port=3306 --ignore_last_failover
切换过程中需要根据提示输入yes。

33.3.16 在线进行切换
业务升级(大表的DDL变更、在线增加索引、硬件升级等)需要进行的切换。
切换过程0.5~2s，将阻塞写入操作。
MHA在线切换过程：
检测复制设置和确定当前主服务器；
确定新的主服务器；
阻塞写入到当前主服务器；
等待所有从服务器赶上复制；
授予写入到新主服务器的权限；
重新设置从服务器。
问题：
自动识别master和slave的问题，通过VIP解决；
负载均衡问题。
切换成功的必备条件：
所有Slave的IO线程和SQL线程状态正常。
所有Slave的show slave status\G的输出中seconds_behind_master参数<=running_updates_limit秒，running_updates_limit默认为1s，可以在切换时指定。
在master端show processlist;输出中所有线程均小于running_updates_limit指定的秒数。
在线切换步骤：
停止MHA监控：
# masterha_stop --conf=/etc/masterha/app1.cnf
手动切换：
# masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive
--new_master_host=新masterIP --new_master_port=3306
--orig_master_is_new_slave --running_updates_limit=10000
切换过程中需要根据提示输入yes。
参数说明：
--orig_master_is_new_slave指将原master变成slave，默认MHA不做上述操作。
--running_updates_limit=10000指切换时允许原Master写入操作小于10s，允许主从延时小于10s。否则可能导致切换失败。

33.3.17 修复宕机的Master
自动切换后的原Master已经故障，等故障修复后可以将原master重新设置成新的slave。
原Master的数据是故障时刻的最新数据，所缺的数据是新Master被启用以后的新增数据。
所以原Master作为新slave时需要指向新Master，并从新Master的初始binlog文件位置开始复制，
该位置信息与其它Slave指向新Master的信息相同，可以从MHA日志文件中提取：
grep -i "All other slaves should start replication from" /master/app1/app1.log
提取到change master to ...即可。

33.4 小结
目前的高可用方案(MMM、MHA、DRBD+Pacemaker、Percona的Galera Cluster)各有优缺点。
出于高可用和数据一致性建议采用MHA。