一、前言简介
此篇前言总结已经Perfect,直接摘抄自:http://www.cnblogs.com/gomysql/p/3675429.html
MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本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,另外一台充当从库,因为至少需要三台服务器,出于机器成本的考虑,淘宝也在该基础上进行了改造,目前淘宝TMHA已经支持一主一从。
我们自己使用其实也可以使用1主1从,但是master主机宕机后无法切换,以及无法补全binlog。master的mysqld进程crash后,还是可以切换成功,以及补全binlog的。
官方介绍:https://code.google.com/p/mysql-master-ha/
图01展示了如何通过MHA Manager管理多组主从复制。可以将MHA工作原理总结为如下:
( 图01 )
(1)从宕机崩溃的master保存二进制日志事件(binlog events);
(2)识别含有最新更新的slave;
(3)应用差异的中继日志(relay log)到其他的slave;
(4)应用从master保存的二进制日志事件(binlog events);
(5)提升一个slave为新的master;
(6)使其他的slave连接新的master进行复制;
个人总结:经发现淘宝的mysql应用使用的是MHA,京东金融用的是MHA ,大部分互联网公司用的介种架构~。个人推荐金融公司,数据公司,对数据容忍是零丢失的,不能容忍故障致业务中断的,推荐此架构!
个人感觉不是架构越复杂越好,在架构可控、均衡的条件下并且出问题的同时快速定位问题点,和有良好的在线扩展能力,以及维护成本低 ~恩,这样才算完美!
二、MHA切换原理和安装部署
备注:因为keepalived 很sb,网络一抖动,keepalived就因为是故障了,就给切了~。
备注:批量打通SSH免密码登陆,可以参考我博客中一篇在线安装大数据集群的文章,里面有讲到怎么批量打通集群的ssh免密码登陆
当然打通之后,安全措施也要做一下,毕竟有的公司安全要求 严格,有人建议是防止应用层利用22端口访问DB服务器。隔离开来。
可以参考此篇文章:
备注:如果大家对Mysql主从复制比较陌生,可以去参考这篇文章:https://www.ztloo.com/2017/02/26/mysql%E5%85%A5%E9%97%A8%E5%88%B0%E7%B2%BE%E9%80%9A/的 【例9-4】复制概念和实现篇
最后MHA需要用到的配置文件分享给大家:
也可以参考这篇文章尝试部署:http://www.cnblogs.com/gomysql/p/3675429.html (好文)
总结分析MHA进行故障处理的过程剖析:http://blog.csdn.net/leshami/article/details/45165929 (好文)
参考资料:DBA贺春旸的PPT
CSDN :http://blog.csdn.net/leshami/article/details/45165929