1.原理：
--从崩溃的master报错二进制日志事件（binlog events）
--识别含有最新更新的slave
--应用差异的relay log到 其他的slave
--应用从master保存的二进制日志事件
--提升一个slave为新的master
--使其他的slave连接到新的master进行复制
MHA软件由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。
目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器
在我们试验的时候：需要准备四个虚拟机，一个做manager，一个做master，剩下两个做slave。
2.实验步骤
（1）给Manager下载安装MHA的一些安装包
cd MHA/
ls
yum install mha4mysql-manager-0.56-0.el6.noarch.rpm perl-* mha4mysql-node-0.56-0.el6.noarch.rpm -y
scp mha4mysql-node-0.56-0.el6.noarch.rpm [email protected](2,3):/root
（2）在master和slave上下载node的安装包
yum install mha4mysql-node-0.56-0.el6.noarch.rpm -y
（3）编写MHA的配置文件
mkdir /etc/masterha
cd /etc/masterha/
ls
vim app1.cnf
[server default]
manager_workdir=/etc/masterha ##工作目录
manager_log=/etc/masterha/manager.log ##设置manager的日志
master_binlog_dir=/var/lib/mysql ##设置master保存binlog的位置，以便MHA可以找到master的日志，我这里的也就是mysql的数据目录
#master_ip_failover_script= /usr/local/bin/master_ip_failover ##设置自动failover时候，切换脚本
#master_ip_online_change_script= /usr/local/bin/master_ip_online_change ##设置failover的时候，手动切换脚本
password=Wang+1212 ##设置mysql中的root用户的密码
user=root ##设置监控用户
ping_interval=1 ##设置监控主库，发送ping包的时间间隔，默认是3秒。常是三次没有回应的时候，则自动进行failover
remote_workdir=/tmp ##社会自远端mysql在发生切换的时候binlog保存的位置
repl_password=Wang+1212 ##设置复制用户的密码
repl_user=repl ##设置复制环境中的复制用户名
#report_script=/usr/local/send_report 设置发生切换后发送的报警的脚本
secondary_check_script=/usr/bin/masterha_secondary_check -s wf1 -s wf2
#shutdown_script="" ##设置故障发生后关闭故障主机脚本
ssh_user=root ##设置ssh的登陆用户名
[server1]
hostname=172.25.254.1
port=3306
[server2]
hostname=172.25.254.2
port=3306
candidate_master=1 ##手动设置如果master挂掉，这个slave将自动切换成为master
check_repl_delay=0
[server3]
hostname=172.25.254.3
port=3306
no_master=1 ##这个命令表示：这台服务器不会去争抢master 这个命令和上面的切换命名二选一添加
masterha_check_ssh --help
masterha_check_ssh --conf=/etc/masterha/app1.cnf ##会出现报错,如下图
<1>需要生成密钥.配置SSH登录无密码验证:
ssh-copy-id 172.25.254.4 ##生成authorized_keys，然后发送到各个结点
<2>发送密钥之前，需要删除之前的 .ssh/:
在wf1，2，3上： rm -fr .ssh/
<3>删除完之前的 .ssh/ 之后，在manager上，将生成的key发送到各个结点上：
scp -r .ssh/ [email protected](2,3):/root
<4>在manager上分别连接各个结点，使其可以直接连接：
ssh 172.25.254.1(2,3)
<5>直接连接后，再重新编译一下 ssh
masterha_check_ssh --conf=/etc/masterha/app1.cnf
masterha_check_repl --conf=/etc/masterha/app1.cnf
##有回出现新的报错，显示root用户访问被拒绝，因此，需要给root用户给与权限
<6>在master上更改权限，因为半同步复制，所有slave也会有。
mysql -p
mysql> grant all on *.* to root@'%' identified by 'Wang+1212';
<7>再次编译：
masterha_check_repl --conf=/etc/masterha/app1.cnf
##回出现新的一个报错，显示slave上可能没有repl这个用户，所以需要添加用户
<8>在master上更改权限，因为半同步复制，所有slave也会有。
mysql -p
mysql> grant replication slave on *.* to repl@'%' identified by 'Wang+1212';
<9>再次在manager上编译：
masterha_check_repl --conf=/etc/masterha/app1.cnf ##编译完成
（4）开启MHA Manager的监控
nohup masterha_manager --conf=/etc/masterha/app1.cnf --ignore_last_failover &
cd /etc/masterha/
ls
cat app1.master_status.health ##查看健康状态启动参数介绍:
=========================================================================================
--remove_dead_master_conf 该参数代表当发生主从切换后，老的主库的ip将会从配置文件中移除。
--manger_log 日志存放位置
--ignore_last_failover 在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件，默认情况下，MHA发生切换后会在日志目录，也就是上面我设置的/data产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为--ignore_last_failover。
4538 0:PING_OK master:172.25.254.1
========================================================================================
========================================================================================
(1)检查SSH配置
masterha_check_ssh --conf=/etc/masterha/app1.cnf 检查MHA Manger到所有MHA Node的SSH连接状态
(2)检查整个复制环境状况:
通过masterha_check_repl脚本查看整个集群的状态
========================================================================================
（5）手动在线切换master
masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=172.25.254.2 --new_master_port=3306 --orig_master_is_new_slave
It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 172.25.35.52(172.25.35.52:3306)? (YES/no): YES
Starting master switch from 172.25.35.52(172.25.35.52:3306) to 172.25.35.54(172.25.35.54:3306)? (yes/NO): yes
master_ip_online_change_script is not defined. If you do not disable writes on the current master manually, applications keep writing on the current master. Is it ok to proceed? (yes/NO): yes
查看切换结果：（注意 原master为1，切换为了2）
<1>在切换以后，登上数据库，因为切换了master，所以导致二进制文件内的事件，有不同，会报错。
所以，要在三个服务器上，reset master 和 reset slave ，然后再开启slave。
原本2是slave，在reset之后，show slave status\G; 就会显示没有slave的状态。
（6）手动故障切换
在master上：
ps ax
kill -9 把所有的相关进程杀掉
在manager上：
masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=dead --dead_master_host=172.25.254.2 --dead_master_post=3306 --new_master_host=172.25.254.1 --new_master_port=3306
Master 172.25.35.54(172.25.35.54:3306) is dead. Proceed? (yes/NO): yes
Starting master switch from 172.25.35.54(172.25.35.54:3306) to 172.25.35.52(172.25.35.52:3306)? (yes/NO): yes
在从master变成slave上：
mysql> change master to master_host='172.25.254.1',master_user='repl',master_password='Wang+1212',master_auto_position=1;
mysql> start slave;
mysql> show slave status\G;
如果还是不行的话，将所有的slave 都reset一下，就好了。
查看切换结果：（注意 原master为2，切换为了1）
（7）自动切换测试
将manager的配置文件删除掉
vim app1.cnf
candidate_master=1
check_repl_delay=0
rm -f mha.failover.complete
nohup masterha_manager --conf=/etc/masterha/app1.cnf --ignore_last_failover &
ps ax
kill -9 把所有的相关进程杀掉
测试：会自动切换
企业——MYSQL高可用之MHA
猜你喜欢
转载自www.cnblogs.com/wf-aiyouwei/p/9850324.html
今日推荐
周排行