一、环境
10.10.31.210 Monitor 10.10.31.211 master 10.10.31.212 Candicate master 10.10.31.213 slave（备份从库）
二、mha安装
1、下载
wget https://72003f4c60f5cc941cd1c7d448fc3c99e0aebaa8.googledrive.com/host/0B1lu97m8-haWeHdGWXp0YVVUSlk/mha4mysql-manager-0.57-0.el7.noarch.rpm wget https://72003f4c60f5cc941cd1c7d448fc3c99e0aebaa8.googledrive.com/host/0B1lu97m8-haWeHdGWXp0YVVUSlk/mha4mysql-node-0.57-0.el7.noarch.rpm
2、安装相关依赖包
yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes -y
3、Monitor节点需要安装manager和node两个包，数据库（主、从）节点只安装node包即可
rpm -ivh mha4mysql-node-0.57-0.el7.noarch.rpm rpm -ivh mha4mysql-manager-0.57-0.el7.noarch.rpm
三、ssh免秘钥登录配置
在所有节点 上执行下面命令，打通所有节点的免密码登录
ssh-keygen -t rsa ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected] ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected] ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected] ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
四、配置主从
主从的配置步骤这里忽略不写了，但是有几个地方需要注意一下
1、能成为主库的节点都加上主从同步账号
10.10.31.211上 GRANT REPLICATION SLAVE ON *.* TO 'slave'@'10.10.31.212' IDENTIFIED by '123456'; GRANT REPLICATION SLAVE ON *.* TO 'slave'@'10.10.31.213' IDENTIFIED by'123456'; 10.10.31.212上 GRANT REPLICATION SLAVE ON *.* TO 'slave'@'10.10.31.211' IDENTIFIED by '123456'; GRANT REPLICATION SLAVE ON *.* TO 'slave'@'10.10.31.213' IDENTIFIED by '123456';
2、所有节点都添加管理账号
GRANT ALL PRIVILEGES ON *.* TO 'root'@'10.10.31.210' IDENTIFIED by '123456'; GRANT ALL PRIVILEGES ON *.* TO 'root'@'10.10.31.211' IDENTIFIED by '123456'; GRANT ALL PRIVILEGES ON *.* TO 'root'@'10.10.31.212' IDENTIFIED by '123456'; GRANT ALL PRIVILEGES ON *.* TO 'root'@'10.10.31.213' IDENTIFIED by '123456';
3、如果设置主从同步过滤条件，那主从库上相关的配置要一样
4、设置从库为只读
set global read_only=1;
5、设置从库的relay_log自动清理机制关闭
set global relay_log_purge=0;
PS：
MHA在发生切换的过程中，从库的恢复过程中依赖于relay log的相关信息，所以这里要将relay log的自动清除设置为OFF，采用手动清除relay log的方式。在默认情况下，从服务器上的中继日志会在SQL线程执行完毕后被自动删除。但是在MHA环境中，这些中继日志在恢复其他从服务器时可能会被用到，因此需要禁用中继日志的自动删除功能。
五、MHA配置 1、撰写监控节点的配置文件
mkdir -p /data/mha/mysql56/tmp vim /data/mha/mysql56/conf/mysql56.cnf [server default] manager_log=/data/mha/mysql56/manager.log manager_workdir=/data/mha/mysql56/tmp master_ip_failover_script=/data/mha/mysql56/scripts/master_ip_failover master_ip_online_change_script=/data/mha/mysql56/scripts/master_ip_online_change password=123456 ping_interval=3 ping_type=CONNECT repl_password=123456 repl_user=slave report_script=/data/mha/mysql56/scripts/send_report ssh_user=root user=root [server1] hostname=10.10.31.210 port=3319 remote_workdir=/data/mha/mysql56/tmp master_binlog_dir=/data/mysql/mysql56/db ignore_fail=1 [server2] remote_workdir=/data/mha/mysql56/tmp master_binlog_dir=/data/mysql/mysql56/db hostname=10.10.31.211 port=3319 candidate_master=1 check_repl_delay=0 ignore_fail=1 [server3] remote_workdir=/data/mha/mysql56/tmp master_binlog_dir=/data/mysql/mysql56/db hostname=10.10.31.212 no_master=1 ignore_fail=1 port=3319
参数解释：
master_ip_failover_script
#故障切换调用这个脚本漂移VIP
master_ip_online_change_script
#在线切换的时候调用这个脚本漂移VIP，比如计划性的维护，我们需要我们需要人为failover到新的主库上
report_script
#故障切换完成后调用这个参数邮件通知dba
user
#MHA管理mysql的用户，做一些主从维护的操作，需要给root权限
password
#MHA管理mysql的root用户的密码
repl_user
#主从同步的账号
repl_password
#主从同步的密码
ping_interval
#设置监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行railover
ping_type
#(从MHA 0.53后开始支持) 在默认情况下， MHA manager和MySQL创建一个连接执行”select 1″（ping_type=select）用于检查master是否健康。
但有一些情况： 每次检测都连接/然后断开会比较好一点，这样对于tcp方面的错误感知更快一点。设置ping_type=CONNECT 就行了。从MHA 0.56后pint_type=INSERT也被添加。
remote_workdir
#MHA node节点 工作需要的目录，如果没有会自动创建，临时存一些差异relay log和binlog文件等等
master_binlog_dir
#定义主节点的binlog的存放的目录
candidate_master=1
#这个参数的作用是当设置candidate_master = 1时，这个服务器有较高的优先级提升为新的master，前提是这个从节点开启了binlog参数还有就没有延时，
#如果设置了多台机器的caddidate_master = 1 , 优先策略依赖于块名字([server_xxx]). [server_1] 优衔权高于[server_2].
check_repl_delay=0
#在默认情况下，当一个slave同步延迟超过100M relay log(需要应用超过100M relay log), MHA在做故障切换时不会选择这个slave做为新的master,因为恢复需要经过很长时间.
当设置了check_repl_delay = 0, MHA将忽略被选择的slave上的同步延迟。 这个选项在设置了candidate_master = 1特声明的期望这台机器成为master的情况下特别有用。
multi_tier_slave
#从MHA 0.52开始, 多层复制可以支持了。在默认情况下，不支持三层或是更多层的复制配置。 如果： host2从host1上复制，host3从host2上复制。 在默认配置的情况下不支持写host{1,2,3}，
因为这是一个三层的复制，MHA Manager会停止报错。 当设置了multi_tier_slave, MHA Manager就不会在三层复制报错停止。 但是会忽略第三层的机器。也就是如果host1挂了，host2将会成为
新的master，host3还是从host2上进行复制。
ignore_fail
#在默认情况下，MHA manager不会在slave存在故障的情况下（已经不能通过SSH/MySQL进行连接，或是SQL Thread已经停止出错，其它原因）的情况下进行Master的故障切换
（当不存在slave时MHA manager也会退出）。 但有些情况下你期望在slave存在问题的情况下，也进行故障切换。 所以当设置了ignore_fail = 1时，MHA会在所有的机器有问题的时间也会进行故障切换。
2、撰写相关脚步（监控节点上）
故障切换漂移VIP的脚步：master_ip_failover.zip
在线切换漂移VIP的脚步：master_ip_online_change.zip
故障切换邮件通知DBA的脚本：send_report.zip
3、需要在主库上先把VIP手动绑定（10.10.31.211）
/sbin/ifconfig eth0:10 10.10.31.250 netmask 255.255.255.0
4、启动监控节点
nohup masterha_manager --conf=/data/mha/mysql56/conf/mysql56.cnf --ignore_last_failover < /dev/null > /data/mha/mysql56/manager.log 2>&1 &
--remove_dead_master_conf # 该参数代表当发生主从切换后，老的主库的相关信息将会从配置文件中移除。 --ignore_last_failover #在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件， 默认情况下，MHA发生切换后会在日志目录，也就是上面我设置的/data产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后 收到删除该文件，为了方便，这里设置为--ignore_last_failover。
六、人工干预的两种切换方法
1、在线切换：
masterha_master_switch --conf=/data/mha/mysql56/conf/mysql56.cnf --master_state=alive --new_master_host=10.10.2.70 --new_master_port=13306 --orig_master_is_new_slave --running_updates_limit=10000
2、主库故障，手动切换：
masterha_master_switch --master_state=dead --conf=/data/mha/mysql56/conf/mysql56.cnf --dead_master_ip= 10.10.31.211 --dead_master_host=10.10.31.211 --dead_master_port=3319 --new_master_host=10.10.31.212 --new_master_port=3319 --orig_master_is_new_slave --running_updates_limit=10000 --interactive=0
--orig_master_is_new_slave #切换时加上此参数是将原 master 变为 slave 节点，如果不加此参数，原来的 master 将不启动 --running_updates_limit=10000 #故障切换时,候选master 如果有延迟的话， mha 切换不能成功，加上此参数表示延迟在此时间范围内都可切换（单位为s），但是切换的时间长短是由recover 时relay 日志的大小决定
七、模拟故障切换
10.10.31.210 Monitor 10.10.31.211 master 10.10.31.212 Candicate master 10.10.31.213 slave（备份从库）
1、在从库213上执行“stop slave io_thread;”模拟主从延时
2、在主库211上执行“create database zhj;” 模拟写入
3、停掉主库211
4、手动切换故障主库，指定新的主库是212
masterha_master_switch --master_state=dead --conf=/data/mha/mysql56/conf/mysql56.cnf --dead_master_ip=10.10.31.211 --dead_master_host=10.10.31.211 --dead_master_port=3319 --new_master_host=10.10.31.212 --new_master_port=3319 --interactive=0
5、验证
查看213是否指定了新的主库212，查看213上是否有故障主库上的写入数据库zhj
八、注意事项
1、通常情况下故障切换以后，原master可能已经废弃掉，待原master主机修复后，如果数据完整的情况下，可能想把原来master重新作为新主库的slave，这时我们可以借助当时自动切换时刻的MHA日志来完成对原master的修复。下面是提取相关日志的命令：
从下面信息可以看到：
Wed May 4 09:30:04 2016 - [info] All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='10.10.31.212', MASTER_PORT=3319, MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=120, MASTER_USER='slave', MASTER_PASSWORD='xxx';
意思是说，如果Master主机修复好了，可以在修复好后的Master执行CHANGE MASTER操作，作为新的slave库。
2、每次切换前需要把manager_workdir目录的之前发生过切换的文件删除，不然会切换不成功
rm -fv /data/mha/mysql56/mysql56.failover.complete
3、手动通过masterha_master_switch 命令切换的前提是masterha_manager进程不要启动