mysql mha sla_MHA的介绍和测试（一）

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相关操作，重新作为从库。

原文：https://www.cnblogs.com/fengzhongzhuzu/p/8848604.html