一:软件简介

MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。

在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。

它由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。

MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。

MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

二:MHA服务

2.1服务角色

MHA 服务有两种角色, MHA Manager(管理节点)和 MHA Node(数据节点):

MHA Manager:  

通常单独部署在一台独立机器上管理多个 master/slave 集群(组),每个 master/slave 集群称作一个 application,用来管理统筹整个集群。

MHA node:  

运行在每台 MySQL 服务器上(master/slave/manager),它通过监控具备解析和清理 logs 功能的脚本来加快故障转移。
  主要是接收管理节点所发出指令的代理,代理需要运行在每一个 mysql 节点上。简单讲 node 就是用来收集从节点服务器上所生成的 bin-log 。对比打算提升为新的主节点之上的从节点的是否拥有并完成操作,如果没有发给新主节点在本地应用后提升为主节点。

由上图我们可以看出,每个复制组内部和 Manager 之间都需要ssh实现无密码互连,只有这样,在 Master 出故障时, Manager 才能顺利的连接进去,实现主从切换功能。

2.2提供的工具

MHA会提供诸多工具程序, 其常见的如下所示:
Manager节点:

masterha_check_ssh :MHA 依赖的 ssh 环境监测工具;

masterha_check_repl :MySQL 复制环境检测工具;

masterga_manager :MHA 服务主程序;

masterha_check_status :MHA 运行状态探测工具;

masterha_master_monitor :MYSQL master 节点可用性监测工具;

masterha_master_swith:master :节点切换工具;

masterha_conf_host :添加或删除配置的节点;

masterha_stop :关闭 MHA 服务的工具。

Node节点:(这些工具通常由MHA Manager的脚本触发,无需人为操作)

save_binary_logs :保存和复制 master 的二进制日志;

apply_diff_relay_logs :识别差异的中继日志事件并应用于其他 slave;

purge_relay_logs :清除中继日志(不会阻塞 SQL 线程);
自定义扩展:
       secondary_check_script :通过多条网络路由检测master的可用性;

master_ip_failover_script :更新application使用的masterip;

report_script :发送报告;

init_conf_load_script :加载初始配置参数;

master_ip_online_change_script ;更新master节点ip地址。

2.3工作原理

原理总结为以下几条:
(1) 从宕机崩溃的 master 保存二进制日志事件(binlog events);
(2) 识别含有最新更新的 slave ;
(3) 应用差异的中继日志(relay log) 到其他 slave ;
(4) 应用从 master 保存的二进制日志事件(binlog events);
(5) 提升一个 slave 为新 master ;
(6) 使用其他的 slave 连接新的 master 进行复制。

三:实现过程

3.1准备Replication环境

3.1.1环境配置

MHA 对 MYSQL 复制环境有特殊要求,例如各节点都要开启二进制日志及中继日志,各从节点必须显示启用其read-only属性,并关闭relay_log_purge功能等,这里对配置做事先说明。
本实验环境共有四个节点, 其角色分配如下(实验机器均为centos 7.3):

为了方便我们后期的操作,我们在各节点的/etc/hosts文件配置内容中添加如下内容:

通过 host 解析节点来打通私钥访问,会方便很多。

192.168.37.111 node1.keer.com node1
192.168.37.122 node2.keer.com node2
192.168.37.133 node3.keer.com node3
192.168.37.144 node4.keer.com node4

3.1.2初始master节点配置

修改 master 的数据库配置文件来对其进行初始化配置:

[root@master ~]# vim /etc/my.cnf
[mysqld]
server-id = //复制集群中的各节点的id均必须唯一
log-bin = master-log //开启二进制日志
relay-log = relay-log //开启中继日志
skip_name_resolve //关闭名称解析(非必须)
[root@master ~]# systemctl restart mariadb

3.1.3所有slave节点依赖配置

修改两个 slave 节点的数据库配置文件:

#slave1节点
[root@slave1 ~]# vim /etc/my.cnf
[mysqld]
server-id = //复制集群中的各节点的id均必须唯一;
relay-log = relay-log //开启中继日志
log-bin = master-log //开启二进制日志
read_only = ON //启用只读属性
relay_log_purge = //是否自动清空不再需要中继日志
skip_name_resolve //关闭名称解析(非必须)
log_slave_updates = //使得更新的数据写进二进制日志中
[root@slave1 ~]# systemctl restart mariadb
#slave2节点
[root@slave2 ~]# vim /etc/my.cnf
[mysqld]
server-id = //复制集群中的各节点的id均必须唯一;
relay-log = relay-log //开启中继日志
log-bin = master-log //开启二进制日志
read_only = ON //启用只读属性
relay_log_purge = //是否自动清空不再需要中继日志
skip_name_resolve //关闭名称解析(非必须)
log_slave_updates = //使得更新的数据写进二进制日志中
[root@slave2 ~]# systemctl restart mariadb

3.1.4配置一主多从复制架构

master节点上:

MariaDB [(none)]>grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer';
MariaDB [(none)]> show master status;

slave节点上:

MariaDB [(none)]> change master to master_host='192.168.37.122',
-> master_user='slave',
-> master_password='keer',
-> master_log_file='mysql-bin.000001',
-> master_log_pos=;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status\G;

3.2MHA安装配置

3.2.1在master上进行授权

在所有 Mysql 节点授权拥有管理权限的用户可在本地网络中有其他节点上远程访问。 当然, 此时仅需要且只能在 master 节点运行类似如下 SQL 语句即可。

MariaDB [(none)]> grant all on *.* to 'mhaadmin'@'192.168.%.%' identified by 'mhapass';

3.2.2配置ssh免秘钥登录

MHA集群中的各节点彼此之间均需要基于ssh互信通信,以实现远程控制及数据管理功能。

简单起见,可在Manager节点生成密钥对儿,并设置其可远程连接本地主机后, 将私钥文件及authorized_keys文件复制给余下的所有节点即可。
下面操作在所有节点上进行:

[root@manager ~]# ssh-keygen -t rsa
[root@manager ~]# ssh-copy-id -i .ssh/id_rsa.pub root@node1

当四台机器都进行了上述操作以后,我们可以在 manager 机器上看到如下文件:

[root@manager ~]# cd .ssh/
[root@manager .ssh]# ls
authorized_keys id_rsa id_rsa.pub known_hosts
[root@manager .ssh]# cat authorized_keys

四台机器的公钥都已经在authorized_keys这个文件中了,接着,我们只需要把这个文件发送至另外三台机器,这四台机器就可以实现 ssh 无密码互通了:

[root@manager .ssh]# scp authorized_keys root@node2:~/.ssh/
[root@manager .ssh]# scp authorized_keys root@node3:~/.ssh/
[root@manager .ssh]# scp authorized_keys root@node4:~/.ssh/

3.2.3安装MHA

四个节点都需安装: mha4mysql-node-0.56-.el6.norch.rpm

Manager 节点需多安装一个: mha4mysql-manager-0.56-.el6.noarch.rpm

使用rz命令分别上传,然后使用yum安装即可。

[root@manager ~]# rz
[root@manager ~]# ls
anaconda-ks.cfg initial-setup-ks.cfg Pictures
Desktop mha4mysql-manager-0.56-.el6.noarch.rpm Public
Documents mha4mysql-node-0.56-.el6.noarch.rpm Templates
Downloads Music Videos
[root@manager ~]# yum install -y mha4mysql-node-0.56-.el6.noarch.rpm
[root@manager ~]# yum install -y mha4mysql-manager-0.56-.el6.noarch.rpm

其余机器也分别进行安装,就不一一举例了。

3.2.4初始化MHA及配置

Manager 节点需要为每个监控的 master/slave 集群提供一个专用的配置文件,而所有的 master/slave 集群也可共享全局配置。全局配置文件默认为 /etc/masterha_default.cnf ,其为可选配置。如果仅监控一组 master/slave 集群,也可直接通过 application 的配置来提供各服务器的默认配置信息。而每个 application 的配置文件路径为自定义。具体操作见下一步骤。

3.2.5定义MHA配置管理文件

为MHA专门创建一个管理用户, 方便以后使用, 在MySQL的主节点上, 三个节点自动同步:

mkdir /etc/mha_master
vim /etc/mha_master/mha.cnf

配置文件内容如下;

[server default]            //适用于server1,2,3个server的配置
user=mhaadmin //mha管理用户
password=mhapass //mha管理密码
manager_workdir=/etc/mha_master/app1 //mha_master自己的工作路径
manager_log=/etc/mha_master/manager.log // mha_master自己的日志文件
remote_workdir=/mydata/mha_master/app1 //每个远程主机的工作目录在何处
ssh_user=root // 基于ssh的密钥认证
repl_user=slave //数据库用户名
repl_password=magedu //数据库密码
ping_interval= //ping间隔时长
[server1] //节点2
hostname=192.168.37.133 //节点2主机地址
ssh_port= //节点2的ssh端口
candidate_master= //将来可不可以成为master候选节点/主节点
[server2]
hostname=192.168.37.133
ssh_port=
candidate_master=
[server3]
hostname=192.168.37.144
ssh_port=
candidate_master=

3.2.6检测4个节点

1)检测各节点间 ssh 互信通信配置是否 ok
     我们在 Manager 机器上输入下述命令来检测:

[root@manager ~]# masterha_check_ssh -conf=/etc/mha_master/mha.cnf

如果最后一行显示为 [info]All SSH connection tests passed successfully 则表示成功。

2)检查管理的MySQL复制集群的连接配置参数是否OK

[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf

我们发现检测失败,这可能是因为从节点上没有账号,因为这个架构,任何一个从节点, 将有可能成为主节点, 所以也需要创建账号。
       因此,我们需要在master节点上再次执行以下操作:

MariaDB [(none)]> grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer';
MariaDB [(none)]> flush privileges;

执行完这段操作之后,我们再次运行检测命令:

[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf
Thu Nov :: - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Thu Nov :: - [info] Reading application default configuration from /etc/mha_master/mha.cnf..
Thu Nov :: - [info] Reading server configuration from /etc/mha_master/mha.cnf..
……
MySQL Replication Health is OK.

3.3启动MHA

在 manager 节点上执行以下命令来启动 MHA:

[root@manager ~]# nohup masterha_manager -conf=/etc/mha_master/mha.cnf &> /etc/mha_master/manager.log &

启动成功以后,我们来查看一下 master 节点的状态:

[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha (pid:) is running(:PING_OK), master:192.168.37.122

上面的信息中“mha (pid:7598) is running(0:PING_OK)”表示MHA服务运行OK,否则, 则会显示为类似“mha is stopped(1:NOT_RUNNING).”
      如果,我们想要停止 MHA ,则需要使用 stop 命令:

[root@manager ~]# masterha_stop -conf=/etc/mha_master/mha.cnf

3.4测试MHA故障转移

3.4.1 模拟主节点数据崩溃

[root@master ~]# killall - mysqld mysqld_safe
[root@master ~]# rm -rf /var/lib/mysql/*

3.4.2 在manger节点查看日志  

[root@manager ~]# tail - /etc/mha_master/manager.log
……
Thu Nov :: - [info] Master failover to 192.168.37.133(192.168.37.133:) completed successfully.

日志显示manager 检测到192.168.37.122节点故障, 而后自动执行故障转移, 将192.168.37.133提升为主节点。

注意,故障转移完成后, manager将会自动停止, 此时使用 masterha_check_status 命令检测将会遇到错误提示, 如下所示:

[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha is stopped(2:NOT_RUNNING).

3.5 提供新的从节点修复集群

原有 master 节点故障后,需要重新准备好一个新的 MySQL 节点。基于来自于master 节点的备份恢复数据后,将其配置为新的 master 的从节点即可。

注意,新加入的节点如果为新增节点,其 IP 地址要配置为原来 master 节点的 IP,否则,还需要修改 mha.cnf 中相应的 ip 地址。随后再次启动 manager ,并再次检测其状态。
    我们就以刚刚关闭的那台主作为新添加的机器,来进行数据库的恢复:
    原本的 slave1 已经成为了新的主机器,所以,我们对其进行完全备份,而后把备份的数据发送到我们新添加的机器上:

[root@slave1 ~]# mkdir /backup
[root@slave1 ~]# mysqldump --all-database > /backup/mysql-backup-`date +%F-%T`-all.sql
[root@slave1 ~]# scp /backup/mysql-backup----\:\:-all.sql root@node2:~

然后在 node2 节点上进行数据恢复:

[root@master ~]# mysql < mysql-backup----\:\:-all.sql

接下来就是配置主从。照例查看一下现在的主的二进制日志和位置,然后就进行如下设置:

MariaDB [(none)]> change master to master_host='192.168.37.133',  master_user='slave',  master_password='keer', master_log_file='mysql-bin.000006', master_log_pos=;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status\G;
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.37.133
Master_User: slave
Master_Port:
Connect_Retry:
Master_Log_File: mysql-bin.
Read_Master_Log_Pos:
Relay_Log_File: mysql-relay-bin.
Relay_Log_Pos:
Relay_Master_Log_File: mysql-bin.
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
……

3.6 新节点提供后再次检查

再次检测状态:

[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf

如果报错,则再次授权(详见上文)。若没有问题,则启动 manager,注意,这次启动要记录日志

[root@manager ~]# masterha_manager -conf=/etc/mha_master/mha.cnf > /etc/mha_master/manager.log >& &
[]

启动成功以后,我们来查看一下 master 节点的状态:

[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha (pid:) is running(:PING_OK), master:192.168.37.133

3.7新节点上线故障恢复注意事项

1)在生产环境中, 当你的主节点挂了后, 一定要在从节点上做一个备份,拿着备份文件把主节点手动提升为从节点, 并指明从哪一个日志文件的位置开始复制;
       2)每一次自动完成转换后, 每一次的(replication health )检测不ok始终都是启动不了必须手动修复主节点, 除非你改配置文件;
       3)手动修复主节点提升为从节点后, 再次运行检测命令;

[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha (pid:) is running(:PING_OK), master:192.168.37.133

4)再次运行起来就恢复成功了;

[root@manager ~]# masterha_manager --conf=/etc/mha_master/mha.cnf

以上的实验已经圆满完成。

MHA实现MySQL的高可用的更多相关文章

  1. 使用MHA实现MySQL主从复制高可用

    一.MHA简介        MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司的youshimaton(现就职于Fac ...

  2. 分布式数据存储 - MySQL主从复制高可用方案

    前面几篇文章说道MySQL数据库的高可用方案主从复制.主从复制的延迟产生原因.延迟检测及延迟解决方案(并未从根本上解决),这种主从复制方案保证数据的冗余的同时可以做读写分离来分担系统压力但是并非是高可 ...

  3. mysql实现高可用架构之MHA

    一.简介 MHA(Master HA)是一款开源的 MySQL 的高可用程序,它为 MySQL 主从复制架构提供了 automating master failover 功能.MHA 在监控到 mas ...

  4. 美团点评MySQL数据库高可用架构从MMM到MHA+Zebra以及MHA+Proxy的演进

    本文介绍最近几年美团点评MySQL数据库高可用架构的演进过程,以及我们在开源技术基础上做的一些创新.同时,也和业界其它方案进行综合对比,了解业界在高可用方面的进展,和未来我们的一些规划和展望. MMM ...

  5. MySQL之高可用MHA部署

    先说一下大概原理 虚拟机A  ip为10.0.3.92           作为master 虚拟机B  ip为10.0.3.102  作为slave1 虚拟机C  ip为10.0.3.103  作为 ...

  6. 技术实战:基于 MHA 方式实现 MySQL 的高可用(转)

    转自:http://os.51cto.com/art/201307/401702_all.htm MHA故障转移可以很好的帮我们解决从库数据的一致性问题,同时最大化挽回故障发生后的数据.本文分享了基于 ...

  7. 基于keepalived搭建MySQL的高可用集群

    MySQL的高可用方案一般有如下几种: keepalived+双主,MHA,MMM,Heartbeat+DRBD,PXC,Galera Cluster 比较常用的是keepalived+双主,MHA和 ...

  8. Keepalived+MySQL实现高可用

    MySQL的高可用方案有很多,比如Cluster,MMM,MHA,DRBD等,这些都比较复杂,我前面的文章也有介绍.最近Oracle官方也推出了Fabric.有时我们不需要这么复杂的环境,这些方案各有 ...

  9. Oracle和MySQL的高可用方案对比【转】

    关于Oracle和MySQL的高可用方案,其实一直想要总结了,就会分为几个系列来简单说说.通过这样的对比,会对两种数据库架构设计上的细节差异有一个基本的认识.Oracle有一套很成熟的解决方案.用我在 ...

随机推荐

  1. 【JavaScript】数组

    [声明一个数组]var a=[1,1,1]; [定义数组的长度]var a=new Array(2); [特殊数组]arguments[0][可以不用声明,当数组内没有东西时可以直接通过方法的参数自动 ...

  2. flask实战-个人博客-虚拟环境、项目结构

    个人博客 博客是典型的CMS(Content Management system,内容管理系统),通常由两部分组成:一部分是博客前台,用来展示开放给所有用户的博客内容:另一部分是博客后台,这部分内容仅 ...

  3. kvm和qemu交互处理io流程

    1.IO虚拟化的分类 (1)全虚拟化:宿主机截获客户机对I/O设备的访问请求,然后通过软件模拟真实的硬件.这种方式对客户机而言非常透明,无需考虑底层硬件的情况,不需要修改操作系统. QEMU模拟I/O ...

  4. [转载]ISO 8601规则

    1.每年有52周或者53周2.周一至周日为一个完整周.3.每周的周一是该周的第1天.周日是该周的第7天4.每年的第一周 为 每年的第一个周四所在的周.比如 2017年1月5日为当年的第一个周四,那么 ...

  5. mysql恢复备份数据时,部分表数据丢失的问题

    原因:是由于默认的通信缓冲区的最大长度为50M(max_allowed_packed). 处理办法: //查看当前max_allowed_packet的大小 show global variables ...

  6. Gradle构建多模块项目

    通常我在使用Maven构建项目的时候是将应用项目划分为多个更小的模块. Gradle 项目也拥有多于一个组件,我们也将其称之为多项目构建(multi-project build). 我们首先创建一个多 ...

  7. NOIP 2017 逛公园 - 动态规划 - 最短路

    题目传送门 传送门 题目大意 给定一个$n$个点$m$条边的带权有向图,问从$1$到$n$的距离不超过最短路长度$K$的路径数. 跑一遍最短路. 一个点拆$K + 1$个点,变成一个DAG上路径计数问 ...

  8. 【Django基本命令002】

    在mac或者window的终端直接输入这些命令(不是Python的shell中) 一.创建Django项目之前必须先激活 具体方法可以参考Python机器语言学习博客 二.开始新建项目 1.新建一个d ...

  9. canvas与svg

    canvas与svg都是用于在网页上绘制图形(位图). canvas是HTML5新出来的一个标签,用来定义一块画图的区域(canvas本身没有绘制能力),用JavaScript来画图,可以绘制路径.矩 ...

  10. zabbix报警逻辑初探

    zabbix报警逻辑初探 首先贴出一张网上找的一张关于zabbix报警相关表结构及表关联逻辑图: actions表 actions表对应前端配置是动作(actions) action由conditio ...