15-MHA高可用软件

发布时间 2023-12-27 15:05:47作者: EJW

1、普通主从复制架构存在的不足

高可用?
业务不间断的工作。
用户的体验不出来业务断点。

普通主从环境,存在的问题:

1、监控的问题:APP应用程序,并不具备监控数据库的功能,没有责任监控数据库是否能连接。
2、选主的问题:
3、failover:VIP漂移,对于应用透明
4、数据补偿

2、企业高可用解决方案:
MMM(过时)
MHA(目前推荐)
PXC、Galera Cluster(出现很多年,企业很少用)
5.7.17 MGR 、Innodb Cluster(未来的趋势,尽早研究)
MySQL NDB Cluster(出现很多年,仍然不完善)
MyCAT 高可用

一、什么是MHA

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

二、MHA架构组成

image

整个MAH架构由两部分组成,即MHA Manager(管理节点),和MHA Node(数据节点),MHA Manager 可以独立部署到一台服务器上(含虚拟机)管理多个主从复制集群,也可已部署到一台从节点上或者其他应用程序上,而MHA Node 需要运行到每一台mysql服务器上

MHA Manager服务器 会定时通过主库上的MHA Node检测主库的运行状态,当主库出现故障时他可以将最优从库(可以提前指定或者由MHA判定)提升为新的主库,然后其他从库和新的主库重新保持新的复制状态

三、MHA工作原理

image

第一种情况 主库实例挂掉但是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  perl-Log-Dispatch perl-Parallel-ForkManager
安装manager节点: rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm

说明:如果安装依赖报错可以访问https://fedoraproject.org/wiki/EPEL,安装相关依赖包
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


vim /etc/mha/app1.cnf
[server default]
master_ip_failover_script=/usr/local/bin/master_ip_failover

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次。

  • candidate_master=1 设置为候选master,如果设置该参数以后,发生主从切换以后将会将此从库提升为主库,即使这个主库不是集群中事件最新的slave
    默认情况下如果一个slave落后master 100M的relay logs的话,MHA将不会选择该slave作为一个新的master,
    因为对于这个slave的恢复需要花费很长时间

  • check_repl_delay=0,
    MHA触发切换在选择一个新的master的时候将会忽略复制延时,这个参数对于设置了candidate_master=1的主机非常有用,
    因为这个候选主在切换的过程中一定是新的
    master