我们是不是一直都忽略了一个问题，当主库挂掉了，MHA是通过主库的binlog给从库补充数据的，但是如果不仅仅是的主节点的MySQL挂掉，连同主节点的主机一起宕机怎么办，SSH都无法连接了，MHA该如何取到binlog呢？那么主从数据库之间相差的数据是不是就不能补上了呢？其实我在前面的章节中就已经把故障分为两类：MySQL宕机，MySQL所在的主机宕机。myMySQLql宕机已经有了方案，下面来看看MySQL所在的主机宕机MHA是如何解决的。

MHA binlog原理
MHA binlog将主库每次提交（commited）的binlog复制到自己指定的位置，并实时一致，当主库所在服务器宕机，MHA此时会将自有的binlog来补充主从之间的数据差值。

准备：
一台装有MySQL5.6以上版本的机器（支持gtid并开启），下面的操作我还是使用装有MHA（db03）主机。

配置步骤：

1. 在主配置/etc/mha/app1.cnf 中填加如下配置：

   [binlog1]
   no_master=1
   hostname=10.0.0.23
   master_binlog_dir=/data/mysql/binlog

   # no_master=1 
   # hostname 为当前节点的IP
   # master_binlog_dir 保存binlog的文件夹

2. 创建/data/mysql/binlog ，并赋权限

   [root@db03 ~]# mkdir -p /data/mysql/binlog
   [root@db03 ~]# chown -R mysql.mysql /data/mysql/*

    

3. 将主库binlog拉过来（从000001开始拉，之后的binlog会自动按顺序过来）

   [root@db03 ~]# cd /data/mysql/binlog   ###必须先进入到该目录中
   [root@db03 binlog]# mysqlbinlog  -R --host=10.0.0.22 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &
   [2] 25140
   [root@db03 binlog]# Warning: Using a password on the command line interface can be insecure.
   
   [root@db03 binlog]# ll
   total 16
   -rw-rw---- 1 root root 427 Aug 28 18:17 mysql-bin.000001
   -rw-rw---- 1 root root 214 Aug 28 18:17 mysql-bin.000002
   -rw-rw---- 1 root root 463 Aug 28 18:17 mysql-bin.000003
   -rw-rw---- 1 root root 120 Aug 28 18:17 mysql-bin.000004
   [root@db03 binlog]# 
   

    

4. 重启MHA，生效配置

   [root@db03 binlog]# masterha_stop --conf=/etc/mha/app1.cnf
   Stopped app1 successfully.
   [1]-  Exit 1                  nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1  (wd: ~)
   (wd now: /data/mysql/binlog)
   [root@db03 binlog]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
   [3] 25184
   [root@db03 binlog]# 

    

5. 测试，刷新binlog，并查看当前日志是否与主库一致。
   主库刷新binlog

   mysql> flush logs;
   Query OK, 0 rows affected (0.03 sec)
   
   mysql> show master log;
   ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'log' at line 1
   mysql> show master logs;
   +------------------+-----------+
   | Log_name         | File_size |
   +------------------+-----------+
   | mysql-bin.000001 |       427 |
   | mysql-bin.000002 |       214 |
   | mysql-bin.000003 |       463 |
   | mysql-bin.000004 |       238 |
   | mysql-bin.000005 |       238 |
   | mysql-bin.000006 |       191 |
   +------------------+-----------+

   查看MHA中的binlog

   [root@db03 binlog]# ll
   total 28
   -rw-rw---- 1 root root 427 Aug 28 18:17 mysql-bin.000001
   -rw-rw---- 1 root root 214 Aug 28 18:17 mysql-bin.000002
   -rw-rw---- 1 root root 463 Aug 28 18:17 mysql-bin.000003
   -rw-rw---- 1 root root 238 Aug 28 18:22 mysql-bin.000004
   -rw-rw---- 1 root root 238 Aug 28 18:24 mysql-bin.000005
   -rw-rw---- 1 root root 238 Aug 28 18:26 mysql-bin.000006
   -rw-rw---- 1 root root 120 Aug 28 18:26 mysql-bin.000007

   ## 与主库binlog保持一致。搞定！！！！！！！！！！！！！！！！！

参数扩展：

• ping_interval=2           #manager检测节点存活的间隔时间，总共会探测4次。配置在[server default]中
• candidate_master=1     #设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的slave，默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间。配置在[server1][server2][server3]。。。节点中
• check_repl_delay=0      #通过设置check_repl_delay=0，MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master，配置在[server1][server2][server3]。。。节点中