Mysql之运用MHA的功能实现服务高可用

时间  2020-03-06
标签 mysql 运用 mha 功能 实现 服务 可用 栏目 MySQL 繁體版
原文   原文链接

MHA介绍 (Master High Availability)node

MHA（Master HA）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供 了 automating master failover 功能。MHA 在监控到 master 节点故障时，会提高其中拥有最新数据的 slave 节点成为新的 master 节点，在此期间，MHA 会经过于其它从节点获取额外信息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。mysql

MHA是由日本人yoshinorim（原就任于DeNA现就任于FaceBook）开发的比较成熟的MySQL高可用方案。MHA可以在30秒内实现故障切换，并能在故障切换中，最大可能的保证数据一致性。目前淘宝也正在开发类似产品TMHA，目前已支持一主一从。linux

MHA服务架构角色定义sql

MHA 服务有两种角色，MHA Manager(管理节点)和 MHA Node(数据节点)： 
MHA Manager： 
一般单独部署在一台独立机器上管理多个 master/slave 集群(组)，每一个 
master/slave 集群称做一个 application，用来管理统筹整个集群。 
MHA node： 
运行在每台 MySQL 服务器上(master/slave/manager)，它经过监控具有解析和清理 logs 功能的脚原本加快故障转移。 
主要是接收管理节点所发出指令的代理，代理须要运行在每个mysql节点上。 
简单讲：node就是用来收集从节点服务器上所生成的bin-log。对比打算提高为新的主节点之上的从节点的是否拥有并完成操做，若是没有发给新主节点在本地应用后提高为主节点。数据库

mysqlmha-1.jpg

如何实现写均衡；ID分或者根据用户名（把用户名hash的结果去对服务器取模）vim

Architecture of MHAbash

MySQL 复制集群中的 master 故障时，MHA 将按以下步骤进行故障转移。服务器

mha-2.png

一、Slave等待咱们的sql线程把本地所复制过来的全部事件，都在本地完成重放 
二、mha_node须要在slave(i)上把latest slave所没有的灰色部分bin-log读取出来传给latest slave，由latest slave在本地补上灰色部分，而后它就成为了主节点，且这个过程是自动进行的，背后实现过程是经过各类程序组件来完成。网络

故障转移原理 
当master出现故障时，经过对比slave之间I/O线程读取master binlog的位置，选取最接近的slave作为latestslave。 其它slave经过与latest slave对比生成差别中继日志。在latest slave上应用从master保存的binlog，同时将latest slave提高为master。最后在其它slave上应用相应的差别中继日志并开始重新的master复制信息。架构

在MHA实现Master故障切换过程当中，MHA Node会试图访问故障的master（经过SSH），若是能够访问（不是硬件故障，好比InnoDB数据文件损坏等），会保存二进制文件，以最大程度保 证数据不丢失。MHA和半同步复制一块儿使用会大大下降数据丢失的危险。

MHA 组件详情

MHA 会提供诸多工具程序，其常见的以下所示。

Manager 节点:

  • masterha_check_ssh：MHA 依赖的 SSH 环境检测工具，各节点要互信；

  • masterha_check_repl：检查MYSQL复制环境是否正常；

  • masterha_manager：MHA 服务器主程序；

  • masterha_check_status：检查MHA 集群工做是否正常；

  • masterha_master_monitor：检查监控MySQL master 主节点是否正常；

  • masterha_master_switch：完成master 节点和slave节点切换的工具；

  • masterha_conf_host：添加或删除配置的节点工具；

  • masterha_stop：关闭 （停）MHA 服务的工具；

Node 节点:

  • save_binary_logs：保存和复制 mysql的master 二进制日志：

  • apply_diff_relay_logs：识别差别的中继日志事件并应用于其它 slave：

  • filter_mysqlbinlog：去除没必要要的 ROLLBACK 事件(MHA 已再也不使用这个工具)：

  • purge_relay_logs：清除中继日志(不会阻塞 SQL 线程)：

自定义扩展(辅助类工具)：

  • secondary_check_script：经过多条网络路由检测 master 的可用性；

  • master_ip_failover_script：更新 application 使用的 masterip；

  • shutdown_script：强制关闭 master 节点；

  • report_script：发送报告；

  • init_conf_load_script：加载初始配置参数；

  • master_ip_online_change_script：更新 master 节点 ip 地址；

测试环境说明和Mysql Replication环境

依据虚拟机搭建四台主机

Master主节点；node2，地址：172.16.5.102 
Slave从节点A；node3，地址：172.16.5.103 
Slave从节点B；node4，地址：172.16.5.104 
MHA管理节点；node5，地址：172.16.5.105

MySQL Replication要求

MHA 对 MySQL 复制环境有特殊要求，各节点都要开启二进制日志及中继日志，各从节点必须显式启用其 read-only 属性，并关闭 relay_log_purge（自动清理日志） 功能等 
同步各个节点上的时间； 
基于主机名进行解析请求； 
各个节点都是基于SSH互信通讯； 
各个节点上都要关闭selinux与iptables

请作如下步骤

[root@node5 ~]# ntpdate cn.ntp.org.cn 各个节点分别执行时间同步
[root@node5 ~]# vim /etc/hosts 修改hosts文件，对如下每主机名进行解析
[root@node5 ~]# setenforce 0 每一个节点上都要作
[root@node5~]# iptables -F 每一个节点上都要作
172.16.5.102 node2.glances.org node2
172.16.5.103 node3.glances.org node3
172.16.5.104 node4.glances.org node4
172.16.5.105 node5.glances.org node5
基于SSH的互信通讯
在MHA管理节点上作以下操做
[root@node5 ~]# ssh-keygen 
[root@node5 ~]# scp -p /root/.ssh/id_rsa.pub /root/.ssh/id_rsa root@node2:/root/.ssh
把以上在MHA管理节点上生成的私钥文件分别复制到其它三个节点上，确保可无需验证登陆
能够在生成后的节点上本身作个测试执行；ssh 172.16.5.105 'date'（第一次须要密码，之后都不须要）
 vim /etc/ssh/ssh_config 
 注释去掉；把StrictHostKeyChecking ask 修改成no，保存退出 （跳过rsa的key验证yes or no）

主节点配置

主机名，node2；地址，172.16.5.102
安装mariadb数据库
yum install mariadb-server
修改配置文件,加入如下内容
vim /etc/my.cnf
innodb_file_per_table=1 //每张表都独立一个idb文件
skip_name_resolve=1 //跳过反向解析
server_id=1 服务器id
relay-log=relay-log //中继日志
log-bin=master-log //二进制日志
保存退出
把配置文件拷贝到另外一台从节点，把server_id改为2
scp /etc/my.cnf root@node3:/etc/my.cnf

从节点配置

主机名，node3；地址，172.16.5.103
其它两台从节点配置文件相同，只要server的ID不同就行
安装mariadb数据库
yum install mariadb-server
修改配置文件,加入如下内容
vim /etc/my.cnf
skip_name_resolve=1
server_id=2
relay-log=relay-log
log-bin=master-log
relay-only=1
relay-log-purge=0
保存退出
把配置文件拷贝到另外一台从节点，把server_id改为3
scp /etc/my.cnf root@node5:/etc/my.cnf

各节点受权和认证操做


主节点1操做； 
[root@node2 ~]# mysql //登陆到mysql，执行下面步骤 
msyql>grant replication slave, replication client on * . * to 'repuser'@'172.16.5.%' identified by 'repuser' 
受权主从节点容许登陆的IP地址和用户 
mysql>show master status; 
查看节点状态，把master-log日志从哪一个位置产生的，记录下来 
mysql>show binlog events in 'master-log.000003'; 
查看下二进制日志事件有没有成功记录，在以上作的受权被事件日志准确记录后，咱们就不须要一个一个去登陆mariadb从节点作认证受权，等咱们启动从节点后会自动同步过去。 
从节点2操做； 
[root@node2 ~]# mysql //登陆到mysql，执行下面步骤 
mysql>change master to master_host='172.16.5.102',master_user='repuser',master_password='repuser',master_log_file='master-log.000003',master_log_pos=594; 
若是从节点在运行中执行 start top； 
msyql>start slave; 
mysql>show slave status\G 
mysql>select host user from mysql.user; 
节点2上面的操做同样在节点3上执行一遍，这样主从复制就成功搭建起来了。 
在主节点上执行建立数据库，修改数据库，看数据会不会自动同步到两个从节点上。 

在各节点上安装MHA

除 了 源 码 包 ， MHA 官 方 也 提 供 了 rpm 格 式 的 程 序 包 ， 其 下 载 地 址 为 https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2。 
CentOS 7 适用于el6 程序包。另外MHA Manage 和 MHA Node 程序包的版本并不强制要求一致。 
安装： 
管理节点：node5，地址：172.16.5.105 
在管理节点安装MHA管理组件，先安装node再安装manager软件自己有依赖关系 
yum install ./mha4mysql-node-0.56-0.el6.noarch.rpm 
yum install ./mha4mysql-manager-0.56-0.el6.noarch.rpm 
把mha4mysql-node-0.56-0.el6.noarch.rpm程序包拷贝到其它三个节点上 
for i in 102 103 104; do scp mha4mysql-node-0.56-0.el6.noarch.rpm 172.16.5.$i:/root/ ;done 
三个节点都必须安装 
node2，地址：172.16.5.102 
node3，地址：172.16.5.103 
node4，地址：172.16.5.104 
yuminstall ./mha4mysql-node-0.56-0.el6.noarch.rpm

初始化MHA

Manger 节点须要为每一个监控的 master/slave 集群提供一个专用的配置文件， 而全部的 master/slave 集群也可共享全局配置。全局配置文件默认为/etc/masterha_default.cnf，其为可选配置。如仅监控一组 master/slave 集群，可直接经过 application 的配置来提供各服务器的默认配置信息。而每一个 application 的配置文件路径为自定义。

MariaDB [(none)]> grant all on *.* to 'mhaadmin'@'172.16.5.%' identified by 'mhaadmin';
MariaDB [(none)]> flush privileges;
为MHA专门建立一个管理用户，方便之后使用，在mysql的主节点上，三个节点自动同步
mkdir /etc/mha_master
vim /etc/mha_master/app1.cnf
配置文件内容以下；
[server default] //适用于server1,2,3个server的配置
user=mhaadmin //mha管理用户
password=mhaadmin //mha管理密码
manager_workdir=/mydata/mha_master/app1 //mha_master本身的工做路径
manager_log=/mydata/mha_master/manager.log // mha_master本身的日志文件
remote_workdir=/mydata/mha_master/app1 //每一个远程主机的工做目录在何处
ssh_user=root // 基于ssh的密钥认证
repl_user=repuser //数据库用户名
repl_password=repuser //数据库密码
ping_interval=1 // ping间隔时长

[server1] //节点1
hostname=172.16.5.102 //节点1主机地址
ssh_port=22 //节点1的ssh端口
candidate_master=1 // 未来可不能够成为master候选节点/主节点

[server2]
hostname=172.16.5.103
ssh_port=22
candidate_master=1

[server2]
hostname=172.16.5.104
ssh_port=22
candidate_master=1

检测各节点间 ssh 互信通讯配置是否 OK

[root@node5 .ssh]# masterha_check_ssh –conf=/etc/mha_master/app1.cnf 
输出信息最后一行相似以下信息，表示其经过检测。 [info] 
All SSH connection tests passed successfully.

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

目的是咱们的数据库定义的用户repuser和密码可否执行复制权限 
[root@node5 ~]# masterha_check_repl –conf=/etc/masterha/app1.cnf 
输出信息以下所示，最后一行的“Health is OK”信息表示经过检测。 
Mon Nov 9 17:22:48 2015 – [info] Slaves settings check done. 
…… 
MySQL Replication Health is OK. 
注意： 
在检查完成后末尾会有两条警号信息 
[warning] master_ip_failover_script is not defined. 
这个是用来定义master_ip地址的故障转移，谁成为主节点后自动把地址转移过去，让它成为主节点，谁成为主节点，谁配置vip（用来配置vip的）须要本身写脚本 
[warning] shutdown_script is not defined. 
这个showdown脚本在安装时已经有了 
rpm -qa mha4mysql-manager ，这个包里有。不用写 
以上两个提供不提供无所谓，只是测试，咱们用其它方式启动

启动 MHA

启动方式用；nohup 后台运行 
若是不用nohup就意味着前台运行，若是终端关了。意味着服务就自动停了！！！ 
第一次启动能够用配置文件启动 
masterha_manager –conf=/etc/mha_master/app1.cnf >/mydata/mha_master/app1/manager.log 2>&1 
直接后台运行，不用输出重定向到某个目录了 
masterha_manager –conf=/etc/mha_master/app1.cnf 
前台运行，更直观 
ok！！！ 
这个时候能够在数据库里作一些操做了，建立数据库，建立表，删除字段，删除表，测试目的 
mysql>create database tbl05; 
mysql>drop database tbl04; 
mysql>use tbl05; 
mysql>create tables

启动成功后，可经过以下命令来查看 master 节点的状态

masterha_check_status --conf=/etc/mha_master/app1.cnf

[root@node5 mydata]# masterha_check_status –conf=/etc/mha_master/app1.cnf 
app1 (pid:3211) is running(0:PING_OK), master:172.16.5.102 
[root@node5 mydata]# 
正常运行中……

若是要中止 MHA，须要使用 masterha_stop 命令

masterha_stop --conf=/etc/mha_master/app1.cnf

[root@node5 mydata]# masterha_stop –conf=/etc/mha_master/app1.cnf

测试故障转移

(1) 在 master 节点关闭 mariadb 服务 
killall mysqld mysqld_safe 
systemctl stop mariadb.service 
(2) 在 manager 节点查看日志 
若是咱们没有记录日志是没有的 
注意，故障转移完成后，manager 将会自动中止，此时使用 masterha_check_status 
命令检测将会遇到错误提示，以下所示。 
[root@node5 ~]# masterha_check_status --conf=/etc/mha-master/app1.cnf 
app1 is stopped(2:NOT_RUNNING) 
(3) 提供新的从节点以修复复制集群 
原有 master 节点故障后，须要从新准备好一个新的 MySQL 节点。基于来自于 master 节点的备份恢复数据后，将其配置为新的 master 的从节点便可。注意，新加入的节点若是为新 增节点，其 IP 地址要配置为原来 master 节点的 IP，不然，还须要修改 app1.cnf 中相应的 ip 地址。随后再次启动 manager，并再次检测其状态。 
(4)新节点提供后再次执行检查操做 
masterha_check_status --conf=/etc/mha_master/app1.cnf 
masterha_check_repl --conf=/etc/mha_master/app1.cnf 
检查无误，再次运行，此次要记录日志 
masterha_manager --conf=/etc/mha_master/app1.cnf >/mydata/mha_master/app1/manager.log 2>&1

新节点上线，故障转换恢复注意事项

(1)、在生产环境中，当你的主节点挂了后，必定要在从节点上作一个备份，拿着备份文件把主节点手动提高为从节点，并指明从哪个日志文件的位置开始复制 
(2)、每一次自动完成转换后，每一次的(replication health )检测不ok始终都是启动不了 
必须手动修复主节点，除非你改配置文件 
(3)、手动修复主节点提高为从节点后，再次运行检测命令 
[root@node5 ~]# masterha_check_repl --conf=/etc/mha_master/app1.cnf 
app1 (pid:3211) is running(0:PING_OK), master:172.16.5.103 
(4)、再次运行起来就恢复成功了 
masterha_manager --conf=/etc/mha_master/app1.cnf

手动完成在线主从节点切换

注意：全部都正常，只是想改一下主节点是谁而已 
masterha_master_switch --master state=alive --conf=/etc/mha_master/app1.cnf 
会提示你在数据库主节点上执行某条语句 
flush no_write_to_binlog tables; //没有写操做的节点，执行flush 
确认，输入yes 
手动检测在各个节点上，把中止的节点手动修复，启用为slave模式

更进一步的提高工做效率

前面三个步骤已经配置了一个基本的MHA 环境。不过为了更多实际应用需求，还需进一步完成以下操做。

(1)、提供额外检测机制，指明对 master 的监控作出误判； 
(2)、在 master 节点上提供虚拟 ip 地址向外提供服务，指明 master 节点转换时，客户端的请求没法正确送达； 
(3)、进行故障转移时对原有 master 节点执行 STONITH 操做以免脑裂； 可经过指定shutdown_script 实现； 
(4)、必要时可进行在线 master 节点转换；

    done！！！

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程