https://www.cnblogs.com/xiaoboluo768/p/5135584.html
环境：
centos 6.5 x64
192.168.0.32 # master
192.168.0.33 #管理节点和从节点slave
VIP：192.168.0.62
iptables打开mysql端口
selinx关闭：
shell > vim /etc/selinux/config
SELINUX=disabled
1.安装mysql 5.5.x以上的版本(如果是5.6以上的版本，不建议开启GTID复制)，并搭建好双主复制，复制用户：repl，复制用户密码：123456
主从复制搭建好后，从库执行下面两个命令(不要加入到my.cnf中，因为从库随时可能被提升为master)
mysql -e 'set global read_only=1;set global relay_log_purge=0;'
如果是刚刚初始化安装完成的mysql，建议进行安全清理：
mysql > delete from mysql.user where user!='root' or host !='localhost';
mysql > truncate table mysql.db;
mysql > drop database test;
mysql > flush privileges;
2.所有服务器之间建立ssh互信（如果管理节点和数据节点共用，要自己能免密钥登录自己）：
在master上：
shell > ssh-keygen -t rsa #创建密钥
shell > ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.33 #发送ssh密钥到其他服务器
shell > ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.32 #发送ssh密钥到自己
在slave上：
shell > ssh-keygen -t rsa #创建密钥
shell > ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.32 #发送ssh密钥到其他服务器
shell > ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.33 #发送ssh密钥到自己
3.安装epel源(所有节点)：
shell > rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-6.noarch.rpm
shell > rpm -ivh http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
4.安装mha（一主一从的架构建议两个节点都安装manager和node包）
MHA的配置，只需要在manager节点上配置即可正常工作，配置文件最少一个，一般可以分成两个部分，这样一个manager管理多个集群时可以少写一点配置（当然，为了方便故障时快速恢复manager，可以在备主上也进行配置一，只是需要把配置里的主动关系做对应修改）：
master:
shell > yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes -y
解压mha_packge.zip:
shell > cd packge
shell > rpm -Uvh mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm
shell > cp -ar masterha /etc/
shell > mkdir /var/log/masterha/app1 -p
slave安装：
shell > yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes -y
解压mha_packge.zip:
shell > cd packge
shell > rpm -Uvh mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm
shell > cp -ar masterha /etc/
shell > mkdir /var/log/masterha/app1 -p
5.配置Mha
master（master中的MHA配置只是用来做备用的，不需要启动管理节点，在主库切换成从库之后，就可以快速切换管理节点，不需要重新配置），全局配置文件内容如下:
shell > cd /etc/masterha
shell > cat masterha_default.conf #修改全局配置文件
[server default]
#MySQL的用户和密码
user=root
password=4testHIGH
#系统ssh用户
ssh_user=root
#复制用户
repl_user=repl
repl_password= 123456
#监控
ping_interval=1
#shutdown_script=""
#切换调用的脚本
master_ip_failover_script= /etc/masterha/master_ip_failover
master_ip_online_change_script= /etc/masterha/master_ip_online_change
修改集群配置文件：
shell > cat app1.conf
[server default]
user=root
password=4testHIGH
#mha manager工作目录
manager_workdir = /var/log/masterha/app1
manager_log = /var/log/masterha/app1/app1.log
remote_workdir = /var/log/masterha/app1
[server1]
hostname=192.168.0.33 #主库的配置上，把从库写成主节点
master_binlog_dir = /data/mysql/data
port=3306
[server2]
hostname=192.168.0.32 #主库的配置上，把主库写成备节点
master_binlog_dir=/data/mysql/data
port=3306
candidate_master=1
check_repl_delay = 0 #用防止master故障时，切换时slave有延迟，卡在那里切不过来。
注：如果有一主多从架构，那么只需要在app1/conf文件后面再多添加几个配置即可，类似如下：
[server3]
hostname=192.168.0.x
port=3306
master_binlog_dir=/data/mysql/data
6.修改master_ip_failover文件中的VIP和绑定网卡
shell > vim /etc/masterha/master_ip_failover
修改master_ip_online_change文件中的VIP和绑定网卡：
shell > vim /etc/masterha/master_ip_online_change
7.把drop_vip.sh和init_vip.sh中的网卡和VIP都改过来
把脚本赋予执行权限：shell > chmod +x drop_vip.sh init_vip.sh master_ip_*
8.这里我为了故障时能快速恢复MHA管理节点，在备主(slave)上也配置了manager，但是不启动：
shell > cd /etc/masterha
shell > cat masterha_default.conf #修改全局配置文件
[server default]
#MySQL的用户和密码
user=root
password=4testHIGH
#系统ssh用户
ssh_user=root
#复制用户
repl_user=repl
repl_password= 123456
#监控
ping_interval=1
#shutdown_script=""
#切换调用的脚本
master_ip_failover_script= /etc/masterha/master_ip_failover
master_ip_online_change_script= /etc/masterha/master_ip_online_change
修改集群配置文件：
shell > cat app1.conf
[server default]
user=root
password=4testHIGH
#mha manager工作目录
manager_workdir = /var/log/masterha/app1
manager_log = /var/log/masterha/app1/app1.log
remote_workdir = /var/log/masterha/app1
[server1]
hostname=192.168.0.32 #从库上的配置，主库就是主节点
master_binlog_dir = /data/mysql/data
port=3306
[server2]
hostname=192.168.0.33 #从库上的配置，从库就是备节点
master_binlog_dir=/data/mysql/data
port=3306
candidate_master=1
check_repl_delay = 0 #用防止master故障时，切换时slave有延迟，卡在那里切不过来。
修改master_ip_failover文件中的VIP和绑定网卡
shell > vim /etc/masterha/master_ip_failover
修改master_ip_online_change文件中的VIP和绑定网卡：
shell > vim /etc/masterha/master_ip_online_change
把drop_vip.sh和init_vip.sh中的网卡和VIP都改过来
把脚本赋予执行权限：shell > chmod +x drop_vip.sh init_vip.sh master_ip_*
9.配置文件测试（一主一从架构的主库和从库上的管理节点建议都要进行测试，不单单只测试从库上的管理节点）：
测试ssh连通性：
shell > masterha_check_ssh --conf=/etc/masterha/app1.conf
注意：如果你是用虚拟机做实验，很可能碰到这步骤报错，碰到两边都无法ssh或者一边可以，一边不可以，此时，可以重新创建密钥试试，如果多次尝试仍然不行，那么就把发起ssh连接而失败的虚拟机换一台再试。或者，看看你的架构是不是把管理节点和数据节点放一起，而管理节点上又没有配置自己到自己免密钥登录。
看到最后提示：[info] All SSH connection tests passed successfully.表示测试通过
测试集群中的主从复制：
shell > masterha_check_repl --conf=/etc/masterha/app1.conf --global_conf=/etc/masterha/masterha_default.conf
注意：执行这个检测命令的时候使用的是user=root帐号去检测，注意user=root帐号也要有远程权限,另外，把mysql目录下的命令做个链接：ln -s /usr/local/mysql/bin/* /usr/bin/
看到最后提示：MySQL Replication Health is OK.表示测试通过
10.启动管理节点(只在从库上启动管理节点)：
启动管理节点最好使用screen启动：
shell > nohup masterha_manager --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --remove_dead_master_conf --ignore_last_failover> /tmp/mha_manager.log 2>&1 &
sh /etc/masterha/init_vip.sh
确认VIP 绑定成功，如果业务按VIP 配置的访问DB，应该已经可以正常访问
注意：
第一次起动，主库上的VIP 不会自动绑定，需要手功调用init_vip.sh 去绑定，主库发生故障切换会进行vip 的漂移
11.启动之后查看控制台输出日志：
/tmp/mha_manager.log
查看app1日志输出：
/var/log/masterha/app1/app1.log
查看master的健康状况日志：
/var/log/masterha/app1/app1.master_status.health
检查是否启动成功：
shell > masterha_check_status --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf
12.切换测试：
1）.在线手工切换（维护切换，需要把MHA监控进程关掉）：
shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --master_state=alive --new_master_host=192.168.0.33 --orig_master_is_new_slave --running_updates_limit=10000
--orig_master_is_new_slave：把旧的master配置为从库
--running_updates_limit=10000：如果主从库同步延迟在10000s内都允许切换，但是但是切换的时间长短是由recover时relay 日志的大小决定
切换成功需要看到类似下面的提示：
info] Switching master to 192.168.0.33(192.168.0.33:3306) completed successfully
同时要查看VIP是否已经漂移到了新的主库上面
2）.故障手工切换（MHA进程没启动或者挂了的同时主库也挂了）：
shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --dead_master_host=old_ip --master_state=dead --new_master_host=new_ip --ignore_last_failover
切换成功需要看到类似如下提示：
Started manual(interactive) failover.
Invalidated master IP address on 192.168.0.32(192.168.0.32:3306)
The latest slave 192.168.0.33(192.168.0.33:3306) has all relay logs for recovery.
Selected 192.168.0.33(192.168.0.33:3306) as a new master.
192.168.0.33(192.168.0.33:3306): OK: Applying all logs succeeded.
192.168.0.33(192.168.0.33:3306): OK: Activated master IP address.
Generating relay diff files from the latest slave succeeded.
192.168.0.33(192.168.0.33:3306): Resetting slave info succeeded.
Master failover to 192.168.0.33(192.168.0.33:3306) completed successfully.
注意：如果是主库服务器还活着，只是mysqld挂了的时候，VIP在切换的时候也会自动漂移，如果是服务器挂了，那么在挂掉的主库重启后，注意不要让VIP随开机启动，因为此时VIP已经漂移到了从库上，从库上可能正在接管业务，故障主库起来后，需要确认数据是否跟新的主库一样，如果一样，那么就把故障主库作为新的从库加入新主库下
3）.故障自动切换（启动MHA监控进程）手动把主库mysqld停掉，观察/var/log/masterha/app1.log日志输出，看到如下信息：
Started automated(non-interactive) failover.
Invalidated master IP address on 192.168.0.32(192.168.0.32:3306)
The latest slave 192.168.0.33(192.168.0.33:3306) has all relay logs for recovery.
Selected 192.168.0.33(192.168.0.33:3306) as a new master.
192.168.0.33(192.168.0.33:3306): OK: Applying all logs succeeded.
192.168.0.33(192.168.0.33:3306): OK: Activated master IP address.
Generating relay diff files from the latest slave succeeded.
192.168.0.33(192.168.0.33:3306): Resetting slave info succeeded.
Master failover to 192.168.0.33(192.168.0.33:3306) completed successfully.
表示成功切换，切换成功后，查看VIP是否漂移到了从库上(切换成功后，MHA进程会自动停止)，同时查看/etc/masterha/app1.conf文件中的[server1]的配置是否都被删除掉了
故障主库起来后，需要确认数据是否跟新的主库一样，如果一样，那么就把故障主库作为新的从库加入新主库下。然后在故障主库上启动MHA进程。
附：
MHA 日常维护命令集：
1）.查看ssh 登陆是否成功
shell > masterha_check_ssh --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf
2）.查看复制是否建立好
shell > masterha_check_repl --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf
3）.检查启动的状态
shell > masterha_check_status--global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf
4）.停止mha
shell > #masterha_stop --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf
5）.启动mha
shell > nohup masterha_manager --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf > /tmp/mha_manager.log < /dev/null 2>&1 &
注意：当有slave 节点宕掉的情况是启动不了的，加上--ignore_fail_on_start 即使有节点宕掉也能启动mha，需要在配置文件中设置ignore_fail=1
6）.failover 后下次重启
每次failover 切换后会在管理目录生成文件app1.failover.complete ，下次在切换的时候会发现有这个文件导致切换不成功，需要手动清理掉。
shell > rm -rf /masterha/app1/app1.failover.complete
也可以加上参数--ignore_last_failover
7）.手工failover
手工failover 场景，master 死掉，但是masterha_manager 没有开启，可以通过手工failover：
shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --dead_master_host=old_ip --master_state=dead --new_master_host=new_ip --ignore_last_failover
8）.masterha_manager 是一种监视和故障转移的程序。另一方面,masterha_master_switch 程序不监控主库。masterha_master_switch 可以用于主库故障转移,也可用于在线总开关。
9）.手动在线切换(master还或者，比如做维护切换时)
shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --master_state=alive --new_master_host=192.168.199.78 --orig_master_is_new_slave
或者
shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --master_state=alive --new_master_host=192.168.199.78 -orig_master_is_new_slave --running_updates_limit=10000
--orig_master_is_new_slave 切换时加上此参数是将原master 变为slave 节点，如果不加此参数，原来的master 将不启动
--running_updates_limit=10000 切换时候选master 如果有延迟的话，mha 切换不能成功，加上此参数表示延迟在此时间范围内都可切换（单位为s），但是切换的时间长短是由recover时relay 日志的大小决定
手动在线切换mha，切换时需要将在运行的mha 停掉后才能切换。
在备库先执行DDL，一般先stop slave，一般不记录mysql 日志，可以通过set SQL_LOG_BIN =0 实现。然后进行一次主备切换操作，再在原来的主库上执行DDL。这种方法适用于增减索引，如果是增加字段就需要额外注意。
注意：Online master switch 开始只有当所有下列条件得到满足。
1）. IO threads on all slaves are running // 在所有slave 上IO 线程运行。
2）. SQL threads on all slaves are running //SQL 线程在所有的slave 上正常运行。
3）. Seconds_Behind_Master on all slaves are less or equal than --running_updates_limit
seconds // 在所有的slaves 上Seconds_Behind_Master 要小于等于running_updates_limit
seconds
4）. On master, none of update queries take more than --running_updates_limit seconds in the
show processlist output // 在主上，没有更新查询操作多于running_updates_limit seconds