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