MySQL高可用架构之MHA-luksl

jiang1799

　　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.1server01监控复制组主服务器（master）172.17.5.2server02写入备用主服务器（candicate master）172.17.5.3server03读从服务器（slave）172.17.5.4server04读　　二、配置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日志的大小决定