MySQL高可用平台需要达到的目标有以下几点:
1、数据一致性保证这个是最基本的同时也是前提,如果主备的数据的不一致,那么切换就无法进行,当然这里的一致性也是一个相对的,但是要做到最终一致性。
2、故障快速切换,当master故障时这里可以是机器故障或者是实例故障,要确保业务能在最短时间切换到备用节点,使得业务受影响时间最短。这里也可以指业务例行维护操作,比如前面提到的无法使用在线进行DDL的DDL操作,很多分表批量的DDL操作,这些操作通过在线切换方式来滚动完成。
3、简化日常维护,通过高可用平台来自动完成高可用的部署、维护、监控等任务,能够最大程度的解放DBA手动操作,提高日常运维效率。
4、统一管理,当复制集很多的情况下,能够统一管理高可用实例信息、实例信息、监控信息、切换信息等。
5、高可用的部署要对现有的数据库架构无影响,如果因为部署高可用,需要更改或者调整数据库架构则会导致成本增加。
6、魅族RDS平台需要高可用支持,这个高可用平台也是作为RDS的一个子模块,为RDS提供高可用支持、切换等服务。
MHA作为线上MySQL高可用方案,主要基于如下几点:
1、自动探测,多重检测
2、部署简单,对现有架构无影响
3、自动补齐数据,维护数据一致性
4、切换过程中支持调用其他脚本的接口
5、支持在线切换
6、开源,perl编写,二次开发相对较容易
7、多实例集中管理
而这些特点中,支持调用外部脚本接口和在线切换尤为重要,当然perl编写,二次开发相对容易,可以根据自己业务需求适当的增加功能也不是难事。
1.1.1 MHA软件介绍
MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在10~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。
MHA能够在较短的时间内实现自动故障检测和故障转移,通常在10-30秒以内;在复制 框架中,MHA能够很好地解决复制过程中的数据一致性问题,由于不需要在现有的 replication中添加额外的服务器,仅需要一个manager节点,而一个Manager能管理多套复制,所以能大大地节约服务器的数量;另外,安装简单,无性能损耗,以及不需要修改现 有的复制部署也是它的优势之处。
MHA还提供在线主库切换的功能,能够安全地切换当前运行的主库到一个新的主库中 (通过将从库提升为主库),大概0.5-2秒内即可完成。
该软件由两部分组成: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.2 MHA工作原理
1、保存master上的所有binlog事件
2、找到含有最新binlog位置点的slave
3、通过中继日志将数据恢复到其他的slave
4、将包含最新binlog位置点的slave提升为master
5、将其他从库slave指向新的master原slave01 并开启主从复制
6、将保存下来的binlog恢复到新的master上
1、监控所有node节点MHA功能说明:
2、自动故障切换(failover)
前提是必须有三个节点存在,并且有两个从库
(1)选主前提,按照配置文件的顺序进行,但是如果此节点后主库100M以上relay-log 就不会选
(2)如果你设置了权重,总会切换带此节点;一般在多地多中心的情况下,一般会把权重设置在本地节点。
(3)选择s1为新主
(4)保存主库binlog日志
3、重新构建主从
(1)将有问题的节点剔除MHA
进行第一阶段数据补偿,S2缺失部分补全90
(2)s1切换角色为新主,将s2指向新主S1
s2 change master to s1
(3) 第二阶段数据补偿
将保存过来的新主和原有主缺失部分的binlog,应用到新主。
(4)虚拟IP漂移到新主,对应用透明无感知
(5)通知管理员故障切换