MHA配置与主的手动切换

一、简介
MHA(Master HA)是一款开源的 MySQL 的高可用程序,它为 MySQL 主从复制架构提供了 automating master failover 功能。MHA 在监控到 master 节点故障时,会提升其中拥有最新数据的 slave 节点成为新的master 节点,在此期间,MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能,即按需切换 master/slave 节点。
  MHA 是由日本人 yoshinorim(原就职于DeNA现就职于FaceBook)开发的比较成熟的 MySQL 高可用方案。MHA 能够在30秒内实现故障切换,并能在故障切换中,最大可能的保证数据一致性。目前淘宝也正在开发相似产品 TMHA, 目前已支持一主一从。

二、MHA 服务
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 才能顺利的连接进去,实现主从切换功能。

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

修改master的配置

vim /etc/my.cnf

server-id=1
log_bin=mysql-log
relay-log=relay-log

systemctl restart mariadb

所有 slave 节点依赖的配置

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       //使得更新的数据写进二进制日志中
systemctl restart mariadb

slave2

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

本步骤完成。

配置一主多从复制架构

点击>一主多从配置<点击

本步骤完成

授权

在 master 上进行授权

   grant all on *.* to 'mha'@'192.168.%.%' identified by '123';  

在两个从上面进行授权 两个从都要做授权

MariaDB [(none)]> grant replication slave on *.* to 'slave'@'%' identified by '123';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)

本步骤完成。

准备 ssh 互通环境

MHA集群中的各节点彼此之间均需要基于ssh互信通信,以实现远程控制及数据管理功能。简单起见,可在Manager节点生成密钥对儿,并设置其可远程连接本地主机后, 将私钥文件及authorized_keys文件复制给余下的所有节点即可。

1.主从和manager的服务器都要做
2.做完后要把每台的私钥都发送给manager
这儿的192.168.242.136是我的managerIP

ssh-keygen -t rsa
ssh-copy-id -i .ssh/id_rsa.pub root@192.168.242.136

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

cd .ssh/
ls
authorized_keys  id_rsa  id_rsa.pub  known_hosts

在这里插入图片描述

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

scp authorized_keys root@192.168.242.133:/root/.ssh/
scp authorized_keys root@192.168.242.134:/root/.ssh/
scp authorized_keys root@192.168.242.135:/root/.ssh/

安装 MHA 包

点击这里>manager包链接<
提取码 : 1111

四个服务器都需安装:mha4mysql-node-0.56-0.el6.norch.rpm

Manager 节点另需要安装:mha4mysql-manager-0.56-0.el6.noarch.rpm

配置MHA配置文件

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

[server default]
user=mha                    **这个是上面在主上面授权的用户和密码**
password=123                #
manager_workdir=/etc/mha_master/app1
manager_log=/etc/mha_master/manager.log
remote_workdir=/mydata/mha_master/app1
ssh_user=root
repl_user=slave            **这个是上面在从上面授权的用户和密码**
repl_password=123          #
ping_interval=1
[server1]
hostname=192.168.242.134
ssh_port=22
candidate_master=1
[server2]
hostname=192.168.242.135
ssh_port=22
candidate_master=1
[server3]
hostname=192.168.242.136
ssh_port=22
candidate_master=1

检测各节点间 ssh 互相通信配置是否 ok

我们在 manager 节点上测试

masterha_check_ssh -conf=/etc/mha_master/mha.cnf

在这里插入图片描述

有底下那个即为成功

检测MHA通信配置是否 ok

我们在 manager 节点上测试

masterha_check_repl -conf=/etc/mha_master/mha.cnf

在这里插入图片描述
此步骤完成。

启动MHA

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

nohup masterha_manager -conf=/etc/mha_master/mha.cnf &> /etc/mha_master/manager.log &

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

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

测试 MHA 故障转移

停止master

systemctl stop mariadb

查看日志

tailf /etc/mha_master/manager.log

在这里插入图片描述

把原主配置为新的从,恢复从这里开始

1 先停掉主库,模拟主库宕机
2 mha将vip切到备库,备库变成主库,应用可以正常读写数据库    【完成】
3 重新启动宕机的原主库【完成】
 systemctl start  mariadb
4 在原主库上建立同步关系(根据宕机时,日志记录的binlog的文件名和偏移量,恢复从这里开始)重新启动原master,开启read_only,并建立同步关系指向新master(根据宕机时,日志记录的binlog的文件名和偏移量,恢复从这里开始)

原主库开启read-only

vim /etc/my.cnf
read_only = ON				//启用只读属性

在这里插入图片描述

MariaDB [(none)]> stop slave ;
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]> show variables like '%read_only%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only     | ON    |
+---------------+-------+
1 row in set (0.00 sec)

MariaDB [(none)]> set global read_only=on;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> change master to master_host='192.168.242.135',master_user='nb',master_password='123',master_log_file='master-log.000003',master_log_pos=669;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> show slave status \G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.242.135
                  Master_User: nb
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: master-log.000003
          Read_Master_Log_Pos: 669
               Relay_Log_File: relay-log.000002
                Relay_Log_Pos: 530
        Relay_Master_Log_File: master-log.000003
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

在manager上操作mha手动切换主库,还原到最初状态,应用可以正常读写数据库

mha手动切换主库,还原到最初状态,应用可以正常读写数据库
想让哪个成为新主,就写那个的IP

masterha_master_switch --conf=/etc/mha_master/mha.cnf    --master_state=alive --new_master_host=192.168.242.134 --new_master_port=3306  --orig_master_is_new_slave

这样就可以实现主的来回切换了

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值