MHA高可用

 

未分类

---

• 如果MHA出错，在从新配置主从复制时需要先对每个库（只清空主库也行）进行清空主从复制然后重新搭建主从复制，主库一定要清空，否则nohup进程启动会出错。
• 进一步高可用：如果nohup进程的服务器宕机了，而正好此时主库的服务器也宕机。所以我们可以给每个从库都装mha管理端，都起nohup进程，这样如果进行一次切换，全部的nohup进程都会掉线。

 

注意的问题

MHA账号系统必须要一致，所以不能给开发两个账号，所以在控制开发的权限的时候只有一种方法就是：给从库设只读。 
而当主库宕机，从库进行切换时，MHA在进行切换的时候可以自动设置只读和解除只读

 

准备工作

 

概念

• 如果MHA部署在一台Slave上，那么它就只能管理一个主从复制结构

• MHA为什么不能部署在master上? 
  本身是防的是主库宕机，如果网络出问题，那么MHA也会失效。

• 完全透明指的是：整个过程MHA日志中会记录的非常详细，方便运维来排查错误。

 

工作流程（原理）

• 从宕机崩溃的master保存的二进制日志文件（binlog events）
• 识别含有最新更新的slave
• 应用差异的中继日志（relay log）到其他的slave
• 应用从master保存的二进制日志实践（binlog events）
• 提升一个slave为新的master
• 使其他的slave连接新的master进行复制 
  原理简单来讲 
  （1）复制主库binlog日志出来 
  （2）找出relaylog日志中最全的从库 
  （3）将最全的relaylog日志所在的所有从库中同步（第一次同步） 
  （4）将之前最全的那个从库提升为主库 
  （5）将复制出来的binlog日志，放到新提升的主库里 
  （6）其他所有从库重新只向新提升的主库，继续主从复制
• 知识点： 
  1.谁的relay log中的内容最多，说明谁的主从复制最快

 

MHA架构图

• 如果只有一个主从复制，就不必要有MHA管理端，直接把它放到主从复制中的一个从库中 
  

 

MHA工具介绍

• masterha_check_ssh:检查ssh连接的一个脚本，MHA要想管理，就必须能ssh到任何一个节点上，如果连不上，MHA是做不到管理的

• masterha_check_repl:检查主从复制，检测谁是主谁是从，有几个架构，能不能完成替换工作（替换就是双主架构，检查从库上有没有开启binlog日志及配置文件中还要加一个东西（从库是不是也能当成主库）。因为它要把从替换为主） 
  
  

 

环境准备

1.三台6.5版本的linux系统，并且都装有mysql（不能是克隆的），给root设置mysql密码

 

mysql二进制安装

• 之后给root用户设置mysql登陆密码

• 尽量不要强杀mysql进程

  配置基于GTID的主从复制

• mysql5.6版本和之前版本的区别:一定程度上缓解了SQL单线程问题，降低了主从复制的延迟

• GTID ：是一种自动追踪（自动同步）进程。如果开始同步，不再需要告诉它从哪开始同步（相当于在从上同步不再需要告诉它从哪个日志的哪个位置开始） 
  特性： 
  （1）支持多线程复制（每个库有一个单独的sql线程） 
  （2）支持启用GTID，在主从复制中，它会自动去找binlog和位置 
  （3）支持延迟复制

• 但是有时候打开GTID反倒麻烦 
  因为GTID一旦打开就控制不了它的同步进程。要想重新控制，必须先关闭GTID。所以，一旦同步出现问题，要先关闭GTID然后进行调整。

 

一.要想做MHA主库和从库的先决条件

 
(3）server-id不能一致

 

二.主库操作

 

三.从库配置

• 之后重启数据库查看状态 
  

 

四.配置主从复制（在从库上）

 

五.mysql配置文件（禁止mysql自动删除relaylog。每个从库都得有，主库也必须有）

• 为什么要禁止mysql自动删除中继日志？怎样设置？MHA要用到relaylog，但是relaylog要占空间，这样的话，长此以往从库的空间不久不够用了，这种情况怎么解决？ 
  mysql有个机制是自动删除中继日志，但是在做MHA时要用到relaylog，所以要把它设置成不能让它自己删，而要把删中继日志的功能交给MHA。 
  永久禁止mysql自动清除relaylog 
  

之后重新启动服务

 

六.部署MHA

1.安装依赖包（所有库上）

• 节点包（每个库上都得安装节点包） 
  

4.配置ssh信任（就是免密钥，在所有节点上配置）

• 在免密钥时，还得自己发自己

6.主从复制检测

• 完了之后在每台服务器上先测试 
  mysql -umha -p666666 -h 本机IP 
  如果不能连上（说明没有密码，需要进行授权） 
  
  那么就要在主库上进行单独授权 
  
• 
  如果出现错误(说明提升为主库的从库上没有主从复制账号，没有主从复制账号，那么其它的从库就不能连接上。) 
  
  解决办法：在给其他从库都加上主从复制账号（账号要一致），因为主从复制账号是在主从复制之前创建的所以从库是没有这个账号的。那么就要给其他从库进行创建账号 
  grant replication slave on *.* to rep@'192.168.200.%' identified by '666666';
  如果成功则显示 
  

 

七.启动MHA

nohup masterha_manager --conf=/etc/mha/mha1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/mha1/manager.log 2>&1 &

 

恢复：

（2）在原本坏了的服务器上

• show slave status是什么都没有的

• 然后粘贴从日志中复制的代码 
  
  之后开启同步

• start slave

• show slave status 
  

• 在配置文件中加入server1的模块 
  vim /etc/mha/mha1.cnf 
  

• 杀掉mha的nohup进程 
  

• 重新启动nohup进程（多按几次回车进行确定），至此恢复完成 
  nohup masterha_manager --conf=/etc/mha/mha1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/mha1/manager.log 2>&1 &

 

存在的问题

虽然MHA搭建完成，但是存在问题 
1.如果主库服务器宕机，那么是怎么把binlog日志复制出来的 
2.从从库切换为主库，IP地址发生改变，但是开发人员是不知道的，那么怎么让它切换以后IP地址不发生改变（使用VIP）

• MHA两个重要的参数 
  如果MHA安装在从库上，那么就得用参数告诉主库不能把这个从库切换为主库，因为如果带有MHA的从库切换为主，要是宕机那么MHA也会宕，因此就不能去完成切换。 
  

 

问题的解决

 

1.怎么在切换的时候不更改IP地址，怎么使用VIP？

通过IP漂移，IP漂移两种方式： 
(1) 通过keepalived的方式管理虚拟IP的漂移 
(2) 通过MHA自带脚本方式，管理虚拟IP的漂移

漂移脚本的方式：

（1）提示：yum安装的manager是没有这个脚本的。 
我们需要从manager的源码包里复制一个。解压manager 

（2）直接创建一个文件叫master_ip_failover,下边是代码（81行，如果算上最后边的空行是82行）

 

 
use warnings FATAL => 'all';

use Getopt::Long;

 
);

 
);

exit &main();

 
}

 
}

 
}

 
}

 

过程

如果启动不成功，可能的原因： 
（1）ssh验证出错 
（2）mha配置文件出错 
（3）主从复制验证出错

如果主库宕机以后，VIP会自动切到转化为主库的从库上

 

2.如果主库的服务宕了，从库可以把binlog日志拿过来，但是如果主库服务器宕机，那么从库是怎么把binlog日志拿过来的？

那么就要在它宕机之前把binlog日志拿过来。所以就需要binlog-server备份服务器（可以做在从库上，不用过于安全） 
（1）.先要修改MHA配置文件 

(3)杀掉mha进程，重新启动

• 这个时候重新启动mha进程，它就检测好几个东西 
  （1）检测ssh 
  （2）检测主从复制 
  （3）检查配置文件 
  （4）检测有没有开启拉日志的进程 
  pkill perl 
nohup masterha_manager --conf=/etc/mha/mha1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/mha1/manager.log 2>&1 &