MySQL高可用架构之MHA

  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进行复制。

  1、部署环境

  大概部署环境以下：（说明：全部系统均为centos7.3，其中server0三、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	读

  2、配置hosts本地解析

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

  

  3、配置四台主机之间ssh免密登录（都须要配置哦）。

  

  4、配置mysql服务。

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

   

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

  

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

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

    

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

  

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

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

    

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

  

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

    

  ④定义MHA管理配置文件。

  在manager（server01）配置：

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

  mkdir -p /etc/mha_master/app1

  修改MHA配置文件以下：

    

  ⑤在master（server02）和slave（server0三、04）建立工做目录

  命令：mkdir /mydata/mha_master/app1

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

   

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

  

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

   

  ⑨启动MHA

  

  5、测试。

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

  systemctl stop mariadb (sserver02)

  

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

  

  ③恢复master（server02）。

  

  6、平常操做

  ①校验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日志的大小决定