解决mysql主服务器单点故障的方法一般常用的有两个mmm和mha,但是一般从真正的高可用的场合,其实最常用的是mha。
如何避免mysql单点故障?
利用mysql主从复制来解决mysql单点故障
如何解决主服务器的单点问题?
主服务器切换后,如何通知应用新的主服务器的ip地址
如何检查mysql主服务器是否可用?
如何处理从服务器和新主服务器之间的那种复制关系?
解决这些问题使用第三方管理组件一种是mmm (Multi-Master Replicatin Manager),它是perl语言开发的一套用于管理mysql主主同步架构的一种工具集,主要作用是,监控和管理mysql的主主复制拓扑,并在当前的主服务器失效时,进行主和主备服务器之间的主从切换和故障转移工作。
MMM提供了自动和手动两种方式移除一组服务器中复制延迟较高的服务器的虚拟ip,同时它还可以备份数据,实现两节点之间的数据同步等。由于MMM无法完全的保证数据一致性,所以MMM适用于对数据的一致性要求不是很高,但是又想最大程度的保证业务可用性的场景。对于那些对数据的一致性要求很高的业务,非常不建议采用MMM这种高可用架构。
MMM监控mysql主从复制健康情况
在主库出现宕机时进行故障转移并自动配置其它从对新主的复制
MMM部署步骤
1、配置主主复制及主从同步集群
2、安装主从节点所需要的支持包
3、安装及配置MMM工具集
4、运行MMM监控服务
5、测试
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已经支持一主一从。另外对于想快速搭建的可以参考:MHA快速搭建
同样是由Perl语言开发的开源工具,可以支持基于GTID的复制模式,MHA在进行故障转移时更不易产生数据丢失,同一个监控节点可以监控多个集群,
需要编写脚本或利用第三方工具来实现vip的配置,MHA启动后只会对数据库进行监控,需要基于ssh免认证配置,存在一定的安全隐患,没有提供从服务器的读负载均很的功能。