1.前言
上一小节主要介绍了MHA的大概的工作原理，但是具体细节上还没有补充，这张就给它补充一下
2.MHA架构
首先我们要知道的是MHA的目的是在于维持Mysql replication中master的高可用性，其最大的特点是可以修复多个slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。
比如说：当master出现故障时，可以通过对比slave之间I/O thread 读取主库binlog的position号，选取最接近的slave做为备选主库（备胎）。其它的从库可以通过与备选主库对比生成差异的中继日志。在备选主库上应用从原来master保存的binlog，同时将备选主库提升为master。最后在其它slave上应用相应的差异中继日志并开始从新的master开始复制。
3.架构工作原理(重点)
当主节点宕机后会发生如下过程：
1.根据配置文件获取所有节点的信息
2.选主阶段(重点)：
(1) 如果判断从库(position或者GTID),数据有差异,最接近于Master的slave,成为备选主
(2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主.
(3) 如果设定有权重(candidate_master=1),按照权重强制指定备选主.
1. 默认情况下如果一个slave落后master 100M的relay logs的话，即使有权重,也会失效.
2. 如果check_repl_delay=0的话,即使落后很多日志,也强制选择其为备选主
3.数据补偿阶段
1.当SSH能连接, 调用save_binary_logs脚本(备选库对比主库GTID 或者position号)，立即保存差异部分的binlog到备选节点上并应用
2.当SSH不能连接, 调用apply_diff_relay_logs脚本，计算从库的relaylog的差异，生成差异的中继日志到给个slave节点上去应用
4.Failover阶段
1.将备选主进行身份切换,对外提供服务
2.其余从库和新主库确认新的主从关系
5. 应用透明(VIP)
前提：需要我们要准备一个master_ip_failover脚本，这个脚本来源于mha4mysql-manager-0.56.tar.gz 软件包，cd samples/scripts/ 这个目录下，我们需要将它复制到/usr/local/bin目录下，这个等会会和配置文件是一一对应的
看看这个脚本(修改后的部分)
my $vip = '172.17.94.100/20'; ###这个ip地址一定是可以访问的，在虚拟机中可以在相应的网段中找出一个没有使用的即可，但是如果是ECS服务器则不能使用VIP，就不能搭建透明代理 my $key = '0'; my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip"; my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";
6. 故障切换通知(send_reprt)
7. 二次数据补偿(binlog_server)
8. 自愈自治(待开发...)
4.配置binlog-server备份服务器
作用：主机宕机，也许会造成主库binlog复制不及时而导致数据丢失的情况出现，因此配置binlog-server进行时时同步备份，是一种不要的安全手段
1.修改配置文件：
vi /etc/mha/app1.cnf 和上面配置一样，但是需要在末尾添加上如下几行 [binlog1] no_master=1 hostname=主库上面的ip地址 master_binlog_dir=/data/3307/binlog/ ###binlog存放位置优先级比全局的高
2.拉取主库上面的binlog日志到一个数据库中存放
- mkidr -p /data/mysql/binlog ###创建存放目录
- mysqlbinlog -R --host=主库的ip地址 -P端口号 --user=mha --password=123 --raw --stop-never mysql-bin.000001 & ##拉取主库的binlog日志
3.其中MHA后台进程
nohup masterha_manager --conf=/etc/mha/mha1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/mha1/manager.log 2>&1 &