MHA实现MySQL的高可用

时间  2019-12-14
标签 mha 实现 mysql 可用 栏目 MySQL 繁體版
原文   原文链接

一：软件简介

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

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

       它由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。mysql

       MHA Manager能够单独部署在一台独立的机器上管理多个master-slave集群，也能够部署在一台slave节点上。sql

       MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它能够自动将最新数据的slave提高为新的master，而后将全部其余的slave从新指向新的master。整个故障转移过程对应用程序彻底透明。数据库

二：MHA服务

2.1服务角色

MHA 服务有两种角色， MHA Manager(管理节点)和 MHA Node(数据节点)：vim

MHA Manager：　　centos

         一般单独部署在一台独立机器上管理多个 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准备实验MySQL的 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 = 1               //复制集群中的各节点的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 = 2               //复制集群中的各节点的id均必须惟一；
    relay-log = relay-log       //开启中继日志
    log-bin = master-log        //开启二进制日志
    read_only = ON              //启用只读属性
    relay_log_purge = 0         //是否自动清空再也不须要中继日志
    skip_name_resolve           //关闭名称解析（非必须）
    log_slave_updates = 1       //使得更新的数据写进二进制日志中
[root@slave1 ~]# systemctl restart mariadb
#slave2节点 [root@slave2 ~]# vim /etc/my.cnf [mysqld] server-id = 3               //复制集群中的各节点的id均必须惟一；
    relay-log = relay-log       //开启中继日志
    log-bin = master-log        //开启二进制日志
    read_only = ON              //启用只读属性
    relay_log_purge = 0         //是否自动清空再也不须要中继日志
    skip_name_resolve           //关闭名称解析（非必须）
    log_slave_updates = 1       //使得更新的数据写进二进制日志中
[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=415; 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-0.el6.norch.rpm 

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

使用rz命令分别上传，而后使用yum安装便可。

[root@manager ~]# rz [root@manager ~]# ls anaconda-ks.cfg  initial-setup-ks.cfg Pictures Desktop mha4mysql-manager-0.56-0.el6.noarch.rpm Public Documents mha4mysql-node-0.56-0.el6.noarch.rpm Templates Downloads Music Videos [root@manager ~]# yum install -y mha4mysql-node-0.56-0.el6.noarch.rpm [root@manager ~]# yum install -y mha4mysql-manager-0.56-0.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=1             //ping间隔时长
[server1]                   //节点2
hostname=192.168.37.133     //节点2主机地址
ssh_port=22                 //节点2的ssh端口
candidate_master=1          //未来可不能够成为master候选节点/主节点
[server2] hostname=192.168.37.133 ssh_port=22 candidate_master=1 [server3] hostname=192.168.37.144 ssh_port=22 candidate_master=1

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 23 09:07:08 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. Thu Nov 23 09:07:08 2017 - [info] Reading application default configuration from /etc/mha_master/mha.cnf.. Thu Nov 23 09:07:08 2017 - [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:7598) is running(0: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 在 master 节点关闭 mariadb 服务,模拟主节点数据崩溃

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

3.4.2 在 manger 节点查看日志　　

[root@manager ~]# tail -200 /etc/mha_master/manager.log …… Thu Nov 23 09:17:19 2017 - [info] Master failover to 192.168.37.133(192.168.37.133:3306) 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-2017-11-23-09\:57\:09-all.sql root@node2:~

      而后在 node2 节点上进行数据恢复：

[root@master ~]# mysql < mysql-backup-2017-11-23-09\:57\:09-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=925; 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: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000006 Read_Master_Log_Pos: 925 Relay_Log_File: mysql-relay-bin.000002 Relay_Log_Pos: 529 Relay_Master_Log_File: mysql-bin.000006 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 2>&1 & [1] 10012

      启动成功之后，咱们来查看一下 master 节点的状态：

[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf mha (pid:9561) is running(0: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:9561) is running(0:PING_OK), master:192.168.37.133

       4）再次运行起来就恢复成功了；

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

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

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