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-keygen -t rsa          以及多次执行ssh-copy-id -i  /root/.ssh/id_rsa.pub   root@172.25.44.x   来实现该节点到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脚本内容 （这个在各大神的日志或博客中均可以找到）