MHA简介：

  MHA是由日本人yoshinorim（原就职于DeNA现就职于FaceBook）开发的比较成熟的MySQL高可用方案。MHA能够在30秒内实现故障切换，并能在故障切换中，最大可能的保证数据一致性。

  该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台mysql服务器上，MHA Manager会定时探测集群中的master节点，当master出故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其它的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

  MHA基本机构图如下：

  

  以上拓扑图展示了如何通过MHA Manager管理多组主从复制。可以将MHA工作原理总结如下：

  （1）从宕机崩溃的master服务器中保存二进制日志事件（binlog events）

  （2）识别含有最新更新的slave

  （3）应用差异的中继日志（relay-log）到其它slave

  （4）应用从master保存的二进制日志事件（binlog events）

  （5）提升一个新的slave为master

  （6）使其它的slave连接新的master进行复制。

  一、部署环境

  大概部署环境如下：（说明：所有系统均为centos7.3，其中server03、server04为server02的从） 

角色	ip	主机名	类型
监测主机（monitor host）	172.17.5.1	server01	监控复制组
主服务器（master）	172.17.5.2	server02	写入
备用主服务器（candicate master）	172.17.5.3	server03	读
从服务器（slave）	172.17.5.4	server04	读

  二、配置hosts本地解析

  ①四台机器配置相同的hosts解析。（也可以在mysql配置文件里配置忽略名字解析skip-name-resolve）

  

  三、配置四台主机之间ssh免密登陆（都需要配置哦）。

  

  四、配置mysql服务。

  ①在master（server02）主机上配置mysql主配置文件

   

  ②在其它三个服务器上配置mysql主配置文件（注意：server-id不一样，其它配置文件都一样）。

  

  ③配置好主从节点之后，按MYSQL复制配置架构的配置方式将其配置完成并启动master节点和各slave节点，以及为各slave节点启动其IO和SQL线程，确保主从复制运行无误。操作如下：

  在master（server02）服务器上授权slave服务器能连接数据库读取二进制日志事物。

    

  在其它机器上获取master的权限，开启复制功能。（三台机器一样）

  

  五、搭建MHA环境和配置服务。

  ①在master（server02）服务器上创建MHA管理复制的账号。

    

  ②在所有服务器上安装mha4mysql-node（我是下载好安装包使用rpm安装的）

  

  ③在监测主机（monitor host）上安装mha4mysql-manager

    

  ④定义MHA管理配置文件。

  在manager（server01）配置：

  定义一个统一管理的用户和目录，方便以后管理。

  mkdir -p /etc/mha_master/app1

  修改MHA配置文件如下：

    

  ⑤在master（server02）和slave（server03、04）创建工作目录

  命令：mkdir /mydata/mha_master/app1

  ⑥检测各节点之间ssh通讯是否ok（server01执行）

   

  ⑦再次在master（server02）执行mysql授权sql语句。【为了确保各slave服务器节点正常，随时可以成为master服务器】

  

  ⑧masterha_check_repl工具检查mysql主从复制是否成功 

   

  ⑨启动MHA

  

  五、测试。

  ①停止master（server02）服务器，查看manager（server01）日志。

  systemctl stop mariadb (sserver02)

  

  ②查看备用slave是否为master了。

  

  ③恢复master（server02）。

  

  六、日常操作

  ①校验ssh等效验证
  $ masterha_check_ssh --conf=/etc/masterha/app1.cnf

  ②校验mysql复制
  $ masterha_check_repl --conf=/etc/masterha/app1.cnf

  ③启动mha监控，在master故障时开启自动转移
  $ nohup masterha_manager --conf=/etc/masterha/app1.cnf > /tmp/mha_manager.log  < /dev/null 2>&1 &

  ###当有slave节点宕掉的情况是启动不了的，加上--ignore_fail_on_start即使有节点宕掉也能启动mha
  $ nohup masterha_manager --conf=/etc/masterha/app1.cnf  --ignore_fail_on_start > /tmp/mha_manager.log  < /dev/null 2>&1 &

  ④检查启动的状态
  $ masterha_check_status --conf=/etc/masterha/app1.cnf

  ⑤停止mha
  $ masterha_stop  --conf=/etc/masterha/app1.cnf

  ⑥多次failover
  MHA在每次failover切换后会在管理目录生成文件app1.failover.complete ，下次在切换的时候如果由于间隔时间太短导致切换不成功，应手动清理掉。
  rm -rf /var/log/masterha/app1/app1.failover.complete或者通过加上参数--ignore_last_failover来忽略

  ⑦手工failover
  手工failover场景，适用于在master死掉，而masterha_manager未开启情形，如下，指定--master_state=dead
  masterha_master_switch --conf=/etc/masterha/app1.cnf --dead_master_host=192.168.1.6 --master_state=dead --new_master_host=192.168.1.7 --ignore_last_failover

  ⑧手动在线切换,如下，指定--master_state=alive
  masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=192.168.1.6 --orig_master_is_new_slave

  masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=192.168.1.6 --orig_master_is_new_slave --running_updates_limit=10000 --orig_master_is_new_slave

  表明在切换时原master变为新master的slave节点
  --running_updates_limit=10000 
  切换时候选master如果有延迟的话，mha切换不能成功，加上此参数表示延迟在此时间范围内都可切换（单位为s），但是切换的时间长短是由recover时relay日志的大小决定

本文转自 LUksl 51CTO博客，原文链接:http://blog.51cto.com/19940919/2043408