MHA 高可用集群详解

一、什么是MHA

  • 传统的主从复制如果主库宕机，其余从库不会自动的代替主库继续工作，这样就不能保证业务的高可用，而MHA就是一个mysql主从复制高可用的解决方案，当主库宕机后，MHA能在1-30秒实现故障检测和故障自动转移，选择一个最优的从库作为主库，同时新的主库还继续与其他从库保持数据一致的状态

二、MHA架构组成

  • 整个MAH架构由两部分组成，即MHA Manager(管理节点)，和MHA Node(数据节点)，MHA Manager 可以独立部署到一台服务器上（含虚拟机）管理多个主从复制集群，也可已部署到一台主从复制从节点上或者其他应用程序上，而MHA Node 需要运行到每一台mysql服务器上 MHA Manager服务器 会定时通过主库上的MHA Node检测主库的运行状态，当主库出现故障时他可以将最优从库（可以提前指定或者由MHA判定）提升为新的主库，然后其他从库和新的主库重新保持新的复制状态

三、MHA工作原理

  • 主库实例挂掉但是ssh还能连接
    1、监控到主库宕机，选择一个新的主，被选择的新主会取消从库的角色（ reset slave）
    选择标准：
    一是根据其他从库的binlog日志的位置选择最新的从库作为新的主库
    二是如果设置了半同步从库，直接选择半同从库作为新的主库
    2、从库通过MHA自带的脚本程序，通过ssh向主库索取缺失部分的binlog
    3、其他从库与新的主库从新构建主从，继续提供服务
    4、如果由vip机制，将VIP从原来的主库漂移到新的主库，让应用无感知
  • 主节点服务器宕机（ssh已经连接不上了）
    1、监控到主机宕机后，尝试ssh连接，连接失败
    2、通过上边所讲的选择标准选择新的主库
    3、计算从库之间的relay-log的差异，补偿到新的其他从库
    4、其他从库从新与新主构建主从关系，继续提供服务
    5、如果由VIP机制，将VIP从原主漂移到新主，让应用无感知
    6、如果有binlog server 机制，会继续将binlog server中缺失的事物，补偿到新的主库

    四、MHA实现

1、三台以上MySQL独立节点实例，节点之间网络正常通信，配置hosts解析
10.0.0.51 主
10.0.0.52 从
10.0.0.53 从 and manager
2、开启GTID复制结构 （show slave status\G）
3、关闭各个结点relay-log自动删除的功能 (show variables like ‘%relay%‘)
vim /etc/my.cnf
relay_log_purge=0
set global relay_log_purge=0;
4、主库创建mha管理用户
grant all privileges on . to mha@‘10.0.0.%‘ identified by ‘mha‘; （会同步到其从节点）
5、配置软连接（mha只能调用/usr/bin/下的命令）
ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql /usr/bin/mysql
6、各节点部署node工具包及依赖包
安装依赖包rpm -ivh perl-DBD-MySQL
安装node节点：rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm（所有实例都要安装）
7、选择其中一个从节点进行部署manager工具包
安装依赖：yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
安装manager节点： rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm
8、在manager上创建配置mah必须要有的工作目录和文件
mkdir -p /etc/mha
mkdir -p /var/log/mha/app1 （可以管理多套主从复制）
创建配置文件 (不需要的配置不要留着，注释没用,切换后会重写)
vim /etc/mha/app1.cnf （serverdefault可以独立）
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
user=mha
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root

[server1]
hostname=10.0.0.51
port=3306

[server2]
hostname=10.0.0.52
port=3306

[server3]
hostname=10.0.0.53
port=3306

9、各节点ssh秘钥互信配置

ssh-keygen -t dsa -P ‘‘ -f ~/.ssh/id_dsa >/dev/null 2>&1

ssh-copy-id -i /root/.ssh/id_dsa.pub root@10.0.0.51
ssh-copy-id -i /root/.ssh/id_dsa.pub root@10.0.0.52
ssh-copy-id -i /root/.ssh/id_dsa.pub root@10.0.0.53

10、检查互信
masterha_check_ssh --conf=/etc/mha/app1.cnf
11、检测主从
masterha_check_repl --conf=/etc/mha/app1.cnf
12、开启MHA功能
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
13、查看启动结果
tail -f /var/log/mha/app1/manager
10.0.0.51(10.0.0.51:3306) (current master)
+--10.0.0.52(10.0.0.52:3306)
+--10.0.0.53(10.0.0.53:3306)
masterha_check_status --conf=/etc/mha/app1.cnf

五、mha故障模拟切换

mha的重点不在于搭建mha,而在于当出现了出现故障之后如何切换和恢复
1、故障模拟，停掉主库，查看manager观察切换过程
tail -f /var/log/mha/app1/manager
2、开启主库（模拟主库已经修好），将原主库从新加入到主从环境
CHANGE MASTER TO MASTER_HOST=‘10.0.0.52‘, MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER=‘repl‘, MASTER_PASSWORD=‘xxx‘;
start slave;
3、将原主库的信息重新加入到manager的配置文件中，配置文件为/etc/mha/app1.cnf（mha故障切换成功后会自动把原主库的信息在配置文件中删除掉）
4、启动mha manager程序（切换成功后manager程序会自动退出）
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
5、查看启动mha状态
masterha_check_status --conf=/etc/mha/app1.cnf

六 、MHAvip地址漂移

1、上传master_ip_failover 文件到 /usr/local/bin/下边
然后修改编码 dos2unix /usr/local/bin/master_ip_failover
2、添加master_ip_failover_script=/usr/local/bin/master_ip_failover到mha的配置文件中/etc/mha/app1.cnf
3、重启mha
masterha_stop --conf=/etc/mha/app1.cnf

nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
4、手工在主库上绑定vip，注意一定要和配置文件中的ethN一致，我的是eth0:1(1是key指定的值)

ifconfig eth0:1 10.0.0.55/24
5、停主库，看vip地址是否漂移成功

七、binlogserver配置使用

binlogserver是配置在MHA环境中单独用来保存主库二进制日志的服务器，要求这台服务器必须要有5.6以上的版本，支持gtid并开启
1、配置manager程序上配置binlogserver
vim /etc/mha/app1.cnf
[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog
2、提前在binlogserver上创建这两个目录
mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/mysql/*

3、修改完成后，将主库binlog拉过来（从000001开始拉，之后的binlog会自动按顺序过来）

cd /data/mysql/binlog --->必须进入到自己创建好的目录
mysqlbinlog -R --host=10.0.0.52 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &

4、重启mha生效
masterha_stop --conf=/etc/mha/app1.cnf

nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &

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

八、mha的其他参数

ping_interval=2 manager检测节点存活的间隔时间，总共会探测4次。
#设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的slave
candidate_master=1
#默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，
因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,
MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，
因为这个候选主在切换的过程中一定是新的master
check_repl_delay=0

原文地址：https://blog.51cto.com/13268236/2364364

时间： 2024-08-03 10:47:21

MHA 高可用集群详解的相关文章

linux下高可用集群详解

1.高可用集群简单效果图 1.1.Messaging Layer:主要收集节点间的事务资源心跳等信息,分别有以下几种: heartbeatV1 heartbeatV2 heartbeatV3 corosync cman keepalived ultramokey 1.2.CRM:cluster resourse manager,对Messaging Layer收集到的资源进行管理,分别有以下几种: Heartbeat v1 自带的资源管理器:haresources Heartbeat v2 自带

MHA高可用集群

MHA高可用集群 文章目录 一.MHA 简介:二.部署 MHA:第一步:三台主从服务器安装 mysql第二步:修改 mysql 的主配置文件:/etc/my.cnf ,注意三台服务器的 server-id 不能一样第三步:三台服务器启动 mysql 服务第四步:配置 Mysql 主从同步(一主两从)第五步:安装 MHA第六步:启动 MHA 一.MHA 简介: MHA(Master High Availability) (1)简介 目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeN

玩转MHA高可用集群

MHA高可用集群 =============================================================================== 概述:  本章将主要介绍MySQL中MHA高可用集群的相关内容,如下: MHA的功能介绍: MHA的集群架构,工作原理: CentOS 7上MHA实战配置部署及故障转移测试: =========================================================================

带你玩转MHA高可用集群

一.简介 MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,现在很多大型的电商网站都采用此解决方案例如:某宝.某东.某会,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内手动或自动(如需自动需结合使用脚本实现)完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用性,就因为有此特性,受到很多大型电

MHA 高可用集群搭建（二）

MHA 高可用集群搭建安装scp远程控制http://www.cnblogs.com/kevingrace/p/5662839.html yum install openssh-clients mysql5.7运行环境:centos6.51 主机部署 manager:192.168.133.141test1: 192.168.133.138test2:192.168.133.139 (为master1的备用)test3: 192.168.133.140 test1为主,test2和test3为备

MySQL数据库——MHA高可用集群架构（实战！！！）

MHA 简介 (1)简介 目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用. (2)该软件由两部分组成 MHA Manager(管理节点)和MHA Node(数据节点)

Mysql MHA高可用集群架构

记得之前发过一篇文章,名字叫<浅析MySQL高可用架构>,之后一直有很多小伙伴在公众号后台或其它渠道问我,何时有相关的深入配置管理文章出来,因此,民工哥,也将对前面的各类架构逐一进行整理,然后发布出来.那么今天将来发布的MHA的架构整体规划与配置操作. 简单介绍MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数

mysql进阶（三）MHA高可用集群

简介: 1.MHA目前在MySQL高可用方面是一个相对成熟的解决方案,是MySQL高可用环境下故障切换和主从提升的高可用软件 2.MHA能在短时间内完成故障切换,并且在最大程度上保证数据的一致性,以达到真正意义上的高可用 3.MHA基于mysql协议,通过mysql主从或主主进行复制 4.MHA官网:https://code.google.com/p/mysql-master-ha/ 软件由两部分组成:MHA Manager(关理节点)和MHA Node(数据节点) 1.MHA Manager可

各种报错，搭建Mysql MHA高可用集群时踩的各种坑

mha下载地址,需要翻墙 https://code.google.com/p/mysql-master-ha/ 管理软件 mha4mysql-manager-0.52-0.noarch.rpm 节点软件 mha4mysql-node-0.52-0.noarch.rpm 环境介绍 Centos6.7 X64 192.168.30.210 monitor 192.168.30.211 db1 (master) 192.168.30.212 db2  (备master) 192.168.30.213