MHA的介绍和测试(一)

时间:2024-10-16 10:36:50

MHA的介绍

MySQL的MHA:MySQL的高级可用性管理器和工具
MHA的主要目标是在短(通常为10-30秒)的停机时间内自动化主故障转移和slave升级,
不受复制一致性问题的困扰,不需要花费大量的新服务器,没有性能损失,
没有复杂性(易于安装),并且不改变现有的部署。
MHA还提供了一种调度在线主切换的方式:
将当前正在运行的主切换到一个新的主服务器,
在几秒钟内(0.5-2秒)的停机时间(仅阻塞写入)。

MHA提供了以下功能,并且在许多部署中都很有用,
比如高可用性、数据完整性、几乎不间断的主维护。

自动主监视和故障转移MHA有一个功能,
可以在现有的复制环境中监控MySQL主服务器,检测主故障,并自动执行主故障转移。
即使一些slave服务器 没有收到最新的中继日志事件,
MHA也会自动识别来自最新slave服务器的不同的中继日志事件,
并将不同的事件应用于其他的slave服务器。所以所有的从服务器都是一致的。
MHA通常可以在几秒内进行故障转移(9-12秒,以检测主故障,可以选择7-10秒来关闭主机,
以避免出现分裂的大脑,在向新主人应用微分传递日志时需要几秒钟,
所以总的停机时间通常是10-30秒)。
另外,您可以在配置文件中定义一个特定的从服务器作为一个主服务器,做备份(设置优先级)。

由于MHA修复了在从服务器之间的一致性,您可以将任何一个从服务器变成主服务器,
而一致性问题(可能导致突然的复制失败)将不会发生。交互式(手动)主故障转移,
您也可以使用MHA进行故障转移,而不是用于监视主机。
您可以使用MHA进行主故障转移交互。
还支持非交互式主故障恢复非交互式主故障转移(不监视主机,而是自动进行故障转移)。
这个特性非常有用,特别是当您已经使用了一个监控MySQL master的软件时。
例如,您可以使用起搏器(心跳)检测主故障和虚拟ip地址接管,
并使用MHA进行主故障转移和从升级。
在许多情况下,在线切换主机到不同的主机,有必要将现有的主机迁移到不同的机器上
(例如,当前的主机在RAID控制器或RAM中有h/w问题,您想用更快的机器来替换)。
这不是主崩溃,但是需要进行主维护来实现这一点。
计划的主维护会导致停机(至少您不能写master),所以应该尽可能快地完成。
另一方面,您应该非常小心地阻塞/杀死当前运行的会话,
因为不同主人之间的一致性问题可能会发生
(i.i。e“更新主1,更新主2,提交主1,在主2上犯错误”将导致数据不一致)。
快速主开关和优美的阻塞写入都是必需的。
MHA提供了一种方法来实现这一点。
您可以在编写器块的0.5-2秒内优雅地切换大师。
在许多情况下,0.5-2秒的作者停机时间是可以接受的,
您甚至可以在不分配计划维护窗口的情况下切换主人。
这意味着您可以采取一些措施,比如升级到更高版本、更快的机器等等

MHA高可用集群测试:

manager:192.168.133.141
master1: 192.168.133.138
master2:192.168.133.139 (为master1的备用)
slave2: 192.168.133.140

从MHA自动failover,我们手动failover,在线切换三种方式来介绍MHA的工作情况

自动failover模拟操作步骤
1 使用sysbench生成测试数据
yum install sysbench -y

2 主库(192.168.133.138)上进行sysbench数据生成,在sbtest库下生成sbtest表,共100W记录
sysbench --test=oltp --oltp-table-size=1000000
--oltp-read-only=off --init-rng=on --num-threads=16
--max-requests=0 --oltp-dist-type=uniform --max-time=1800
--mysql-user=root --mysql-socket=/tmp/mysql.sock
--mysql-password=123456 --db-driver=mysql --mysql-table-engine=innodb
--oltp-test-mode=complex prepare

3 停掉slave sql线程,模拟主从延时,另外一台slave我们没有停止io线程,所以还在继续接收日志。
stop slave io_thread;

4模拟sysbench压力测试
主库上(192.168.133.138)进行压力测试,持续时间为3分钟,产生大量的binlog
sysbench --test=oltp --oltp-table-size=1000000
--oltp-read-only=off --init-rng=on --num-threads=16
--max-requests=0 --oltp-dist-type=uniform --max-time=180
--mysql-user=root --mysql-socket=/tmp/mysql.sock
--mysql-password=123456 --db-driver=mysql --mysql-table-engine=innodb
--oltp-test-mode=complex run

5开启master2(192.168.0.60)上的IO线程,追赶落后于master的binlog
start slave io_thread;

6杀掉主库mysql进程,模拟主库发生故障,进行自动failover操作
pkill -9 mysqld

7查看MHA切换日志,了解整个切换过程,在192.168.133.141上查看日志
cat /var/log/masterha/app1/manager.log
看到最后的Master failover to 192.168.0.60(192.168.0.60:3306) completed successfully.
说明备选master现在已经上位了。

包括以下的步骤
1.配置文件检查阶段,这个阶段会检查整个集群配置文件配置
2.宕机的master处理,这个阶段包括虚拟ip摘除操作,主机关机操作(这个我这里还没有实现,需要研究)
3.复制dead maste和最新slave相差的relay log,并保存到MHA Manger具体的目录下
4.识别含有最新更新的slave
5.应用从master保存的二进制日志事件(binlog events)
6.提升一个slave为新的master进行复制
7.使其他的slave连接新的master进行复制
切换后监控会停止

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

*******************************************************************
********************************************************************
#####################################################################

在线迁移考虑问题:
1.自动识别master和slave的问题(master的机器可能会切换),
如果采用了vip的方式,基本可以解决这个问题。

2.负载均衡的问题(可以定义大概的读写比例,每台机器可承担的负载比例,
当有机器离开集群时,需要考虑这个问题)

MHA需要满足的条件:
1.所有slave的IO线程都在运行
2.所有slave的SQL线程都在运行
3.所有的show slave status的输出中
Seconds_Behind_Master参数小于或者等于running_updates_limit秒,
如果在切换过程中不指定running_updates_limit,那么默认情况下running_updates_limit为1秒。
4.在master端,通过show processlist输出,
没有一个更新花费的时间大于running_updates_limit秒
****************************************************************************************
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
****************************************************************************************
步骤:
停掉MHA监控
masterha_stop --conf=/etc/masterha/app1.cnf
进行在线切换操作(模拟在线切换主库操作,
原主库变为slave,另一个提升为新的主库)

masterha_master_switch --conf=/etc/masterha/app1.cnf
--master_state=alive --new_master_host=192.168.0.60
--new_master_port=3306 --orig_master_is_new_slave
--running_updates_limit=10000

--orig_master_is_new_slave 切换时加上此参数是将原master变为slave节点,
如果不加此参数,原来的 master 将不启动

--running_updates_limit=10000,故障切换时,
候选master如果有延迟的话, mha 切换不能成功,
加上此参数表示延迟在此时间范围内都可切换(单位为s),
但是切换的时间长短是由recover 时relay 日志的大小决定

由于在线进行切换需要调用到master_ip_online_change这个脚本,
但是由于该脚本不完整,需要自己进行相应的修改,
脚本中new_master_password这个变量获取不到,导
致在线切换失败,所以进行了相关的硬编码,
直接把mysql的root用户密码赋值给变量new_master_password,
这个脚本还可以管理vip

**************************************************************************
***************************************************************************
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

四.修复宕机的Master

通常情况下自动切换以后,原master可能已经废弃掉,
待原master主机修复后,如果数据完整的情况下,
可能想把原来master重新作为新主库的slave,
这时我们可以借助当时自动切换时刻的MHA日志来完成对原master的修复
grep -i "All other slaves should start" manager.log

Mon Apr 21 22:28:33 2014 - [info]
All other slaves should start replication from here.
Statement should be:
CHANGE MASTER TO MASTER_HOST='192.168.133.139', MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000022', MASTER_LOG_POS=506,
MASTER_USER='backup', MASTER_PASSWORD='backup';

获取上述信息后,直接在修复后的master上执行change master to相关操作,重新作为从库。