1.切换过程会自动把read_only关闭

2.切换之后需要删除手工删除/masterha/app1/app1.failover.complete,才能进行第二次测试

3.一旦发生切换管理进程将会退出,无法进行再次测试,需将故障数据库加入到MHA环境中来

4.原主节点重新加入到MHA时只能设置为slave,在之前需要先 reset slave

RESET SLAVE;
CHANGE MASTER TO MASTER_HOST='192.168.121.165',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='xxxxxx',MASTER_AUTO_POSITION=508;
START SLAVE;
SHOW SLAVE STATUS\G;

5、ip地址的接管有几种方式,这里采用的是MHA自动调用IP别名的方式,好处是在能够保证数据库状态与业务IP切换的一致性。启动管理节点
之后VIP会自动别名到当前主节点上,Keepalived也只能做到对3306的健康检查,但是做不到比如像MySQL复制中的Slave-SQL、Slave-IO进程的检查,容易出现对切换的误判。

6.注意:二级从服务器需要将log_slave_updates打开

7.手工切换需要先定义好master_ip_online_change_script脚本,不然只会切换mysql,IP地址不会绑定上去,可以根据模板来配置该脚本

8.通过设置no_master=1可以让某一个节点永远不成为新的主节点

恢复集群运行

在manager上删除app1.failover.complete文件

cd /masterha/app1
rm -f default.failover.complete 

原master主节点服务启动

service mysql start 

检查原master主节点上数据库内容和原Slave1上一致以后,可以进行切换操作
原master主节点停止slave、设置read_only为OFF

stop slave;
set global read_only=1;

原Slave1上启动slave、设置read_only为ON

start slave;
set global read_only=0;

manager管理节点,检查同步

masterha_check_repl --conf=/etc/masterha/default.cnf

需注意:按如上步骤操作后,此时163节点作为slaver已加入到集群中,但是宕机这段时间165、166中新产生的数据在163中没有,所以还需要先从主节点备份导入最新的数据再启动同步
启动MHA

nohup masterha_manager --conf=/etc/masterha/default.cnf > /mha/app1/mha_manager.log &

回切:
同样的道理,以上步骤配置无问题的话停止当前master的MySQL进程,MHA可直接切换master至原节点(需要修改default.cnf配置文件)

带符号 * 的表示必填项