MHA提供了3种方式用于实现故障转移，分别自动故障转移，需要启用MHA监控；在无监控的情况下的手动故障转移以及基于在线手动切换。三种方式可以应对MySQL主从故障的任意场景。本文主要描述在无监控的情形是手动实现故障转移。供大家参考。
有关MHA的其他两种切换方式，可以参考：
1、手动故障转移的特点
? ? a、在监控节点未启用masterha_manager
? ? b、master库已经宕机或者转移到高性能服务器
? ? c、手动故障转移支持交互或非交互两种模式
? ? d、切换样例：$ masterha_master_switch --master_state=dead --conf=/etc/app1.cnf --dead_master_host=host1
2、masterha_master_switch切换的几个参数
--master_state=dead
? ? ? 强制参数为"dead" 或者 "alive". dead为手动故障转移，alive为在线切换。
?
--dead_master_host=(hostname)
? ? ? 强制参数为主机名，另2个--dead_master_ip --dead_master_port(缺省3306)可选。
?
--new_master_host=(hostname)
? ? ? 可选参数，用于指定新master，如果未指定则按candidate_master参数设定值。
?
--interactive=(0|1)
? ? ? 可选参数，指定是否交互。缺省为1，表明交互。
3、演示手动故障转移
###环境?
[root@vdbsrv1 ~]# more /etc/hosts
127.0.0.1? ? localhost.localdomain localhost
192.168.1.6? vdbsrv1? #master
192.168.1.7? vdbsrv2? #slave1
192.168.1.8? vdbsrv3? #slave2
192.168.1.12 vdbsrv4? #manager
?
###master开启VIP
[root@vdbsrv4 ~]# ssh vdbsrv1 "/sbin/ifconfig eth0:0 192.168.1.13 netmask 255.255.255.0 up"
###检测MHA监控是否运行，如果已启动，可以使用masterha_check_stop先停止
[root@vdbsrv4 ~]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RUNNING).
###模拟从库滞后
[root@vdbsrv4 ~]# ssh vdbsrv2 "mysql -e 'stop slave io_thread'"
[root@vdbsrv4 ~]# ssh vdbsrv2 "mysql -e 'show slave status\G' | egrep 'Slave_IO|Slave_SQL'"
? ? ? ? ? ? ? Slave_IO_State:
? ? ? ? ? ? Slave_IO_Running: No
? ? ? ? ? ? Slave_SQL_Running: Yes
? ? ? Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
###主库上插入新记录
mysql> insert into tb(val,dt) values('john',current_date());
Query OK, 1 row affected (0.01 sec)
###模拟master异常宕机
[root@vdbsrv4 ~]# ssh vdbsrv1 "killall -r mysqld"
###开始手工故障转移
[root@vdbsrv4 ~]# masterha_master_switch --master_state=dead --conf=/etc/masterha/app1.cnf --dead_master_host=vdbsrv1 \
>? --dead_master_port=3306 --new_master_host=vdbsrv3 --new_master_port=3306 --ignore_last_failover
--dead_master_ip=
Wed Apr 22 11:48:39 2015 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Wed Apr 22 11:48:39 2015 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
Wed Apr 22 11:48:39 2015 - [info] Reading server configuration from /etc/masterha/app1.cnf..
Wed Apr 22 11:48:39 2015 - [info] MHA::MasterFailover version 0.56.
Wed Apr 22 11:48:39 2015 - [info] Starting master failover.
Wed Apr 22 11:48:39 2015 - [info]
Wed Apr 22 11:48:39 2015 - [info] * Phase 1: Configuration Check Phase..
Wed Apr 22 11:48:39 2015 - [info]
Wed Apr 22 11:48:39 2015 - [info] GTID failover mode = 0
Wed Apr 22 11:48:39 2015 - [info] Dead Servers:
Wed Apr 22 11:48:39 2015 - [info]? vdbsrv1(192.168.1.6:3306)
Wed Apr 22 11:48:39 2015 - [info] Checking master reachability via MySQL(double check)...
Wed Apr 22 11:48:39 2015 - [info]? ok.
Wed Apr 22 11:48:39 2015 - [info] Alive Servers:
Wed Apr 22 11:48:39 2015 - [info]? vdbsrv2(192.168.1.7:3306)
Wed Apr 22 11:48:39 2015 - [info]? vdbsrv3(192.168.1.8:3306)
Wed Apr 22 11:48:39 2015 - [info] Alive Slaves:
Wed Apr 22 11:48:39 2015 - [info]? vdbsrv2(192.168.1.7:3306)? Version=5.6.22-log (oldest major version between slaves) log-bin:enabled
Wed Apr 22 11:48:39 2015 - [info]? ? Replicating from 192.168.1.6(192.168.1.6:3306)
Wed Apr 22 11:48:39 2015 - [info]? vdbsrv3(192.168.1.8:3306)? Version=5.6.22-log (oldest major version between sla