binlog output.. done.
Cleaning up test file(s).. done.
Fri Aug 7 15:27:25 2015 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user=mha --slave_host=10.10.10.58 --slave_ip=10.10.10.58 --slave_port=3306 --workdir=/tmp --target_version=5.6.25-log --manager_version=0.53 --relay_log_info=/data/mysql/relay-log.info --relay_dir=/data/mysql/ --slave_pass=xxx
Fri Aug 7 15:27:25 2015 - [info] Connecting to root@10.10.10.58(10.10.10.58:1022)..
Checking slave recovery environment settings..
Opening /data/mysql/relay-log.info ... ok.
Relay log found at /data/mysql, up to net-app1b-relay-bin.000011
Temporary relay log file is /data/mysql/net-app1b-relay-bin.000011
Testing mysql connection and privileges..Warning: Using a password on the command line interface can be insecure.
done.
Testing mysqlbinlog output.. done.
Cleaning up test file(s).. done.
Fri Aug 7 15:27:26 2015 - [info] Slaves settings check done.
Fri Aug 7 15:27:26 2015 - [info]
10.10.10.56 (current master)
+--10.10.10.57
+--10.10.10.58
Fri Aug 7 15:27:26 2015 - [info] Checking replication health on 10.10.10.57..
Fri Aug 7 15:27:26 2015 - [info] ok.
Fri Aug 7 15:27:26 2015 - [info] Checking replication health on 10.10.10.58..
Fri Aug 7 15:27:26 2015 - [info] ok.
Fri Aug 7 15:27:26 2015 - [warning] master_ip_failover_script is not defined.
Fri Aug 7 15:27:26 2015 - [warning] shutdown_script is not defined.
Fri Aug 7 15:27:26 2015 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK. 最后是ok的了，这是什么原因呢？
根据官方文件说明：
In common HA environments, many cases people allocate one virtual IP address on a master. If the master crashes, HA software like Pacemaker takes over the virtual IP address to the standby server.
Another common approach is creating a global catalog database that has all mappings between application names and writer/reader IP addresses (i.e. {app1_master1, 192.168.0.1}, {app_master2, 192.168.0.2}, …), instead of using virtual IP addresses. In this case, you need to update the catalog database when the current master dies.
Both approaches have advantages and disadvantages. MHA does not force one approach, but allow users to use any IP address failover solution. master_ip_failover_script parameter can be used for that purpose. In other words, you need to write a script to make applications transparently connect to the new master, and have to define at master_ip_failover_script parameter. Here is an example. 大体意思是在高可用环境中，我们可以在主master和备用master使用vip，以便在主master宕机时，vip可以漂移到备用master继续提供服务，而不用更改程序代码；还有一种方式是使用全局配置文件。而这两种方式都已优缺点，MHA不会强制我们使用哪一种方式，但是我们无论使用哪种方式，都可以用到master_ip_failover_script，我们只需要设置相关参数即可。
为了便于我们充分了解相关脚本命令，我们将/etc/mha/app1.conf中的相关执行脚本的命令行全都注释掉，通过手动执行的方式来体验下，在弄明白所有脚本后我们在自动执行。
8.开启mha manager监控
[root@rd-mysql-test4 scripts]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &
我们可以使用nohup来使监控运行在后台。
其中：
--remove_dead_master_conf 该参数代表当发生主从切换后，老的主库的ip将会从配置文件中移除。
--manger_log 日志存放位置
--ignore_last_failover 在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件，默认情况下，MHA发生切换后会在日志目录，也就是上面我设置的/data产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为--ignore_last_fai