mysql 高可用之mha实现
一
mha简介
mha是由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套MySQL环境下故障切换和主从提升的高可用软件。据说可以在0~30秒内完成主从切换，
并且在切换过程中可以最大限度的保持数据一致性，当然本人认为保持数据一致性这个问题，一定程度依赖于所搭建的主从复制的工作模式
##实际检验时 做过不同主从复制模式下的mha高可用 结论是在经典方式下 似乎mha工作更加稳定
二
mha工作模式
mha在master宕机时的工作过程大致如下
（1）从宕机崩溃的master保存二进制日志事件（binlog events）;
（2）识别含有最新更新的slave;
（3）应用差异的中继日志(relay log) 到其他slave;
（4）应用从master保存的二进制日志事件(binlog events);
（5）提升一个slave为新master;
（6）使用其他的slave连接新的master进行复制。
三mha工作原理
mha是完全由perl语言编写开发的 大致结构分为manager & node两部分 manager和node分别包含不同的perl脚本 但是核心功能依赖于node部分的脚本
所以所有的节点都应有node部分的脚本 而manager部分的脚本只需要在manager节点上有即可
并且 所有的perl脚本运行都依赖于同一个cnf文件 也就是说 mha的大体结构就是一堆的perl脚本 然后他们运行时都要以这个cnf 作为参数 读取其中的配置信息
来保证自己的正常运行
四
实验环境
首先 所有节点要安装perl解释器 以及mysql对应的perl模块 （DBD:mysql）
并且 至少拥有三个节点 也就是三个mysql节点 并且实现一主两从的复制
这里笔者使用的是经典复制模式 关于如何配置经典复制模式 可以参考笔者以前的博客 mysql 5.7 主从复制
所以这里不再赘述
并且 系统版本 Redhat6.5 mysql版本5.7 mha版本0.56 rpm格式
主从环境：
172.25.44.3 master
172.25.44.4 备用master
172.25.44.1 slave以及manger #（实在是内存有限 一旦开启很多虚拟化节点就很影响实验体验 \尬 所以把manager和slave配置在同一节点）
五
配置开始
首先在所有节点yum install mha4mysql-node-0.56 -y
并在manger节点安装 mha4mysql-manager-0.56 注意此时应该已经配置好主从复制
这里笔者的rpm安装过后 所有的脚本都放在/usr/bin/ 目录下 只要找到脚本 vim查看内容即可发现 脚本要求的通用cnf文件位置以及名称 这个文件不是rpm包自带的 没有默认示范
需要自行创建目录 并自己手写这个文件 或者更改所有脚本 改所有脚本岂不是很麻烦 所以这里我还是mkdir老老实实满足脚本所需的目录
然后这个app1.cnf内容如下
manager _log #manager进程启动后生成的日志位置
manager_workdir #manager进程的工作空间
master_binlog_dir #master节点binglog存放位置 即 mysql的数据目录
master_ip_failover_script #master down之后 监控自动执行的change master 管理vip漂移脚本
master_ip_online_change_script #master down 手动failover切换master 管理vip脚本
user & password #监控用户以及密码 在所有节点上都要授权该用户以及监控权限
ping intervial #manager 用来 ping master节点的频率
remote_workdir #从远端的节点发生切换时 binlog保存位置
repl_user&repl_password #复制用户 用户名及密码 所有节点授权 复制权限
ssh_user #ssh用户名密码
report_script #master 宕机时发送邮件警告所用的脚本
shutdown_script #类似于fence机制的强制PowerOff故障节点的脚本
接下来就说说mha正常启动的流程吧
首先要有上文所说的app1.cnf
然后我们就要迎来比较恐怖的三次check
分别是mha的三个check脚本 masterha_check_ssh masterha_check_repl masterha_check_status
其实坑比较多的是第二个repl的check 检查各种情况下的主从同步 这个最难搞
并且只有三个check 全部通过 mha才能正常运行
首先是第一个ssh的check 他要求 manager节点对所有节点免密ssh登陆 以及其他node节点之间相互免密ssh登陆
我们再这里要在各个节点执行 ssh-****** -t rsa 以及多次执行ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected] 来实现该节点到172.25.44.x节点的ssh免密
完成之后执行 masterha_check_ssh --conf=/usr/local/masterha/app1.cnf
验证ssh是否通过
ssh check通过 接下来我们 执行 masterha_check_repl --conf=/usr/local/masterha/app1.cnf 模拟各种情况下的复制
果不其然有报错 但是mha虽然结构很简单 就是一堆的perl脚本 但是不得不说报错这点上 作者还是相当用心 基本从报错中就可以清楚的看到为什么没有通过 十分的详细
他这里说我们有两个节点的slave是没有正常运行的 那么我们进入mysql解决
eg：这里笔者已经做过repl用户（复制用户）以及look用户（监控用户）的授权 如果是新建环境 必须先做这两个用户的授权 切记！！
这里有一个关键的坑点 所有的从库必须设置read_only 因为mha是在主从同步基础上的 所以一定要防止手动方式或其他外力方式修改从库内容 导致从库复制过来的binlog
在自己本地无法执行 那么 slave的sql线程就会挂掉 无法实现同步 也就是说 所有的slave数据变更完全由同步机制实现 不允许其他实现
这里我们看到两个yes 说明change master成功 主从复制开启
再次check repl 成功
然后这里我是手动给master节点上了一个vip 因为是脚本实现failover 所以要手动上一个vip
而且这里还有一个小坑点 必须是 ifconfig eth0:1 172.25.44.100/24 这样的命令 加上去的 如果ip addr后没有eth0:1 那么将来他宕机以后 脚本不能down掉他的vip
因为我进去看了他的脚本 脚本就是在你的master节点的bash上执行 一个ifconfig ethx:1 172.25.x.100 down 这个命令 如果不是一模一样的vip 命令就无法生效
就会发生两个节点争抢vip的情况
下面我们要执行最后一个check status之前 应当先把监控打开 因为他mha默认是监控自动failover的
使用nohup masterha_manager + 各种参数 + & 打入后台 运行
--remove_dead_master_conf #将宕机的master从app1.cnf中剔除
--ignore_last_failover #忽略最近的failover日志 这里也有一个小坑点 mha的默认是两次检测到宕机的时间间隔如过不超过8小时 那么不执行failover
切换master vip漂移 实验环境没有那么长的时间间隔 它每次完成切换后会在 manager进程的工作目录留下一个 failover_complete文件 如果检测到这个文件存在
那么即使检测到宕机 也默认不切换 为了防止ping-pong 所以我们要手动加参数忽略这个文件
之后我们查看 /usr/local/masterha/manager.log 管理进程的文件 里面对当前整个manager-node点中的各个节点的状态都有检测 主要还是检测master
节点 如果我们看到末尾的 ping (select) succeed ,waiting until mysql doesn't response 那么说明整个点的监控已经正常运行了
我们可以看到在manager进程的工作目录下 有failover.complete的文件 以及master状态的master_status.health文件 还有从宕机master中抢救过来的binlog文件
然后我们stop掉master的mysql 模拟宕机
然后继续监控manager进程的日志文件 可以发现manager进程已经检测到宕机 并迅速的执行比对数据 抢救binlog 选举新master vip漂移 并在slave上
重新change master以及relaylog 同步数据等等一系列操作 不得不说日志真是详细 mha很强大
这时我们切到宕机的master上 发现我们手动添加的vip已经飘走
新master上的slave状态被reset
存活的slave上的slave状态已经被重新 change master 并且已经完成了relaylog（这里截图有限 已经看不到了）
下面就是mha的一些源脚本内容 可以看到全局配置文件的指定（在document块中）
以及我所使用的的master_ip_failover脚本内容 （这个在各大神的日志或博客中均可以找到）