数据库架构：一主两从
master：192.168.8.57
slave1：192.168.8.58
slave2：192.168.8.59
manager：192.168.8.60
MHA工具包：
mha4mysql-manager-0.58.tar.gz
mha4mysql-node-0.58.tar.gz
keepalived-1.4.5.tar.gz
一、环境配置过程如下：
http://blog.itpub.net/30135314/viewspace-2217762/
二、切换测试
1.在192.168.8.57关闭MySQL进程
2.查看MHA manager日志
可以看到192.168.8.57上MySQL进程宕掉之后，新主库切至192.168.8.58，和192.168.8.59形成新的主从环境。
3.查看VIP
VIP192.168.8.88/24已经飘至192.168.8.58机器。
4.查看slave进程
192.168.8.58
192.168.8.59
可以看到从库192.168.8.59的主库变成192.168.8.58
5.测试复制
19开发云主机域名2.168.8.58（主库）
192.168.8.59（从库）
新的主从数据复制正常。
三、将旧主库加入复制环境
修复完192.168.8.57之后，将此节点变成从库加入到环境当中，可以直接change master to
查看t10有没有复制到192.168.8.57
修改/etc/masterha/app1.cnf，将[server1]添加上
四、将复制还原到原始状态（主库为192.168.8.57）
1.重置复制
192.168.8.57
192.168.8.58
192.168.8.59
2.重启192.168.8.57和192.168.8.58上边keepalived进程，使VIP飘至192.168.8.57。
3.重启MHA manager进程并观察复制情况。
MGR出现的问题大概总结为以下几点： 1．每次提交事务时尽量控制单次操作事务的数据量，减少大事物在其他节点check的时间和堵塞后面的操作带来的集群复制延迟，如事务回滚影响更大； 2．MGR集群环境部署对网络的依赖性较强，网络延时会导致整个集群性能的下降，集群…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
