（项目六）Mha-Atlas-MySQL高可用方案实践

mha-mysql环境准备：

三台虚拟机，都安装了mysql，都关闭防火墙和selinux，同时在每台虚拟机上都作映射

软件包

1） mha管理节点安装包：

mha4mysql-manager-0.56-0.el6.noarch.rpm

mha4mysql-manager-0.56.tar.gz

2） mha node节点安装包：

mha4mysql-node-0.56-0.el6.noarch.rpm

mha4mysql-node-0.56.tar.gz

3） mysql中间件：

Atlas-2.2.1.el6.x86_64.rpm

4） mysql源码安装包

mysql-5.6.17-linux-glibc2.5-x86_64.tar

注意，mysql的安装包必定要用5.6版本及以上

 软件简介

• MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，是一套优秀的做为MySQL高可用性环境下故障切换和主从提高的高可用软件。在MySQL故障切换过程当中，MHA能作到0~30秒以内自动完成数据库的故障切换操做，而且在进行故障切换过程当中，MHA能最大程度上保证数据库的一致性，以达到真正意义上的高可用。
• MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager能够独立部署在一台独立的机器上管理多个Master-Slave集群，也能够部署在一台Slave上。当Master出现故障时，它能够自动将最新数据的Slave提高为新的Master，而后将全部其余的Slave从新指向新的Master。整个故障转移过程对应程序是彻底透明的。

工做流程

• 从宕机崩溃的master保存二进制日志事件（binlog events）；
• 识别含有最新更新的slave；
• 应用差别的中继日志（relay log）到其余的slave；
• 应用从master保存的二进制日志事件（binlog events）；
• 提高一个slave为新的master；
• 使其余的slave链接新的master进行复制；

 MHA架构图

MHA工具介绍

MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明以下：

1. #Manager工具包主要包括如下几个工具：
2. masterha_check_ssh #检查MHA的SSH配置情况
3. masterha_check_repl #检查MySQL复制情况
4. masterha_check_status #检测当前MHA运行状态
5. masterha_master_monitor #检测master是否宕机
6. masterha_manger #启动MHA
7. masterha_master_switch #控制故障转移（自动或者手动）
8. masterha_conf_host #添加或删除配置的server信息
9. masterha_secondary_check #试图创建TCP链接从远程服务器
10. masterha_stop #中止MHA
11. #Node工具包主要包括如下几个工具：
12. save_binary_logs #保存和复制master的二进制日志
13. apply_diff_relay_logs #识别差别的中继日志事件
14. filter_mysqlbinlog #去除没必要要的ROLLBACK事件
15. purge_relay_logs #清除中继日志

mysql安装过程略（在安装以前先安装ncurses-devel 和 libaio，本地yum便可安装 ）

在安装完mysql后设置密码：mysqladmin -uroot password ‘123456’

配置基于GTID的主从复制

先决条件

• 主库和从库都要开启binlog
• 主库和从库server-id不一样
• 要有主从复制用户

打开了GTID，就控制不了同步过程，一旦出现问题，得先关闭GTID才能修改

主库操做（Mysql-Master）

修改配置文件  （主要是开启二进制日志和server id）

修改完配置文件要重启mysqld服务

建立主从复制用户

 从库操做（Mysql-slave1和Mysql-slave2）

从库配置文件和主库同样，只须要修改server id 便可，我把Mysql-slave1的改成5，Mysql-slave2的改成10，改完记得重启mysqld服务

特别提示：
在以往若是是基于binlog日志的主从复制，则必需要记住主库的master状态信息。

可是在MySQL5.6版本里多了一个Gtid的功能，能够自动记录主从复制位置点的信息，并在日志中输出出来。

开启GTID

 修改配置文件，在mysqld模块加三条语句

[mysqld]

gtid_mode = ON
log_slave_updates
enforce_gtid_consistency

 三台虚拟机都得加，加完后重启服务。

 

改完后查看GTID状态

 

 

再次提示： 

从库都必需要开启GTID，不然在作主从复制的时候就会报错.

 

主库配置主从复制(Mysql-slave1，Mysql-slave2)

 

 

开启从库的主从复制功能(Mysql-slave1，Mysql-slave2)

 

 

两个从库都执行以上步骤

从库设置(Mysql-slave1，Mysql-slave2)

须要把从库的relay-log日志自动删除功能给关闭，修改配置文件

 

改完须要重启服务

部署MHA

环境准备（全部节点Mysql-master，Mysql-slave1，Mysql-slave2）

 

主库上建立该帐号从库会自动复制

部署管理节点（mha-manager）

在mysql-slave2上部署管理节点

使用阿里云源+epel源

wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-6.repo

wget -O /etc/yum.repos.d/epel-6.repo http://mirrors.aliyun.com/repo/epel-6.repo

而后yum -y install perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes

 

 rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm

编辑配置文件

建立配置文件目录    mkdir -p /etc/mha

建立日志目录     mkdir -p /var/log/mha/mha1

建立配置文件（默认没有）

 

以上配置文件内容里每行的最后不要留有空格

特别说明： 
参数：candidate_master=1
解释：设置为候选master，若是设置该参数之后，发生主从切换之后会将此从库提高为主库，即便这个主库不是集群中事件最新的slave
参数：check_repl_delay=0
解释：默认状况下若是一个slave落后master 100M的relay logs 的话，MHA将不会选择该slave做为一个新的master，由于对于这个slave的恢复须要花费很长时间，经过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机很是有用，由于这个候选主在切换的过程当中必定是新的master

配置ssh信任（全部节点Mysql-master，Mysql-slave1，Mysql-slave2）

每一个虚拟机都建立密钥对 ssh-keygen -t dsa -P "" -f ~/.ssh/id_dsa

每一个虚拟机的公钥都分发给全部虚拟机（包括本身）

 

 

启动测试

ssh检查检测

 

出现上图最后一行，表示成功

主从复制检测

（1）错误的主从复制检测

 

最后一行显示出错，你们应该都是这样的，这是说明Mysql-slave1和Mysql-slave2上没有主从复制帐号

所以在Mysql-slave1和Mysql-slave2上添加主从复制的用户便可。

grant replication slave on *.* to rep@'192.168.200.%' identified by '123123';

注意，建立完主从复制帐号要刷新一下，不然仍是会报错

flush  privileges；

再次检查

 

 

启动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 &