查看原文
其他

爱奇艺 MySQL 高可用方案到底有多牛?

数据库服务团队 开发者技术前线 2023-09-18

点击“开发者技术前线”,选择“星标🔝”

让一部分开发者看到未来

写在前面




爱奇艺每天都为数以亿计的用户提供7x24小时不间断的视频服务。通过爱奇艺的平台,用户可以方便的获取海量、优质、高清的视频资源。但如果服务平台出现故障,会有大量的用户将无法正常播放视频,因此我们的应用服务以及数据库服务都必须具备高可用架构。

爱奇艺技术产品团队对各类应用划分了不同的重要等级,对不同重要等级的应用使用数据库服务提供了不同的SLA保障。比如S级应用RTO控制在分钟级别的保障;对A级应用RTO在10分钟级别的保障等。本文将主要介绍我们的MySQL高可用实现方案。


自研MySQL HA系统


1.基于MHA二次开发

MHA是目前比较成熟及流行的MySQL高可用解决方案,很多互联网公司正是直接使用或者基于MHA的架构进行改造实现MySQL的高可用。MHA能在30秒内对故障进行转移,并最大程度的保障数据的一致性。MHA由两个模块组成:Manager 和 Node。

Manager部署在独立的机器上,负责检查MySQL复制状态、主库状态以及执行切换操作。Node运行在每台MySQL机器上,主要负责保存和复制master binlog、识别主库宕机时各Slave差异的中继日志并将差异的事务应用到其他的Slave,同时还负责清除Slave上的relay_log。

它的部署架构如下图所示:

MHA虽然已经比较成熟,但也存在一些的缺点:

  • 使用配置文件管理主备关系、不能重复切换
  • 实例增减需要重启Manager
  • Manager是单点,虽然有standby的节点,但不能自动切换

另外我们的MySQL部署环境复杂,存在跨DC跨地域的部署,新主的选举需要更多的规则。并且集群数量较为庞大,如果直接采用MHA做高可靠用,会大大增加管理成本。因此我们自研了一套MySQL的高可用方案。


2. MySQL HA架构简介

爱奇艺自研MysQL HA系统由HA Master和HA Agent两部分组成。三个HA Master组成一个最小集群单元,这个最小集群单元对应MHA的Manager,通过raft协议实现高可用,解决Manager单点和不能重复切换的问题。HA Agent功能和MHA Node功能类似,负责责故障检测、解析和传输 binlog、清理 relay log 以 及负责 MGR 的高可用。

(1)HA Master

整个MySQL HA部分,体现出设计原则思路,有难点的部分重点如下。

切换模块则负责具体的故障切换,通过定期轮训badinstance集合,对符合条件的实例进行切换。支持自动和手动两种切换方式。对于自动切换,需要在CMDB里配置好切换策略,可选同DC切换、跨DC切换还是跨地域切换。

切换流程如图所示:

除了对主库支持故障切换外,也具备对从库故障切换的能力。在从库故障宕机时,通过检测故障,再操作域名的方式实现Slave的高可用。

(2)HA Agent

Agent负责监控CMDB里状态为online的实例,通过检查mysqld进程是否存在等规则判断实例是否存活,如果判断实例宕机则向HA Master发送包含badinstance的RPC心跳。如果是机器宕机,HA Master会收到Agent的超时事件,并对心跳超时的Agent所在服务器上的实例进行切换。为了尽量避免网络抖动造成误切,我们把Agent超时时长设置为1分钟,1分钟内的闪断或者抖动不做切换。

Agent还负责对MGR的Primary节点进行监控和域名切换。MGR在主节点发生切换后,客户端需要去捕获这个切换信息,再把请求重新指向新的主节点,这对于业务来说不友好。因此我们给Agent增加一个功能,当发现主节点发生过切换后,就把源主节点上的域名重绑到新的主节点上,从而实现MGR故障切换对业务的透明。


3. HA的选主规则

HA需要一套复杂的选主规则,用以适配我们复杂的部署环境,选主规则如下:

  1. 排除在bad slaves里的slave
  2. 选择所有latest slaves优先级最高的candidate master
  3. 如果从库没有设置优先级,选出所有非bad slaves的slave
  4. 根据切换策略,依次选择同DC→同region→跨region的slave
  5. 对满足条件的从库,排除从库所在机器Master个数和Slave个数太多的salve,在剩下的slave中选择机器剩余磁盘空间最大的slave
通过以上规则,选出一个最优的主进行切换。如果没有满足条件的slave,则会通过电话告警的方式通知DBA进行人工干预。


4. 补全diff binlog

在Master切换过程中,会存在3种类型的diff binlog:

  1. 从库io thread接收到的relay log不完整,不是一个完整的事务或完整的binlog event

  2. lastest slave与其他slave存在的diff relay log

  3. 如果dead master机器还能访问, 则还包括dead master未发送的diff binlog

diff binlog的恢复顺序如图所示:

如果是使用gtid复制,需要生成3种diff binlog文件,然后顺序apply diff binlog文件,恢复从库。非gtid复制,先change master到lastest slave,先让slave从lastest slave恢复数据,然后再apply dead master未发送的diff binlog 文件,完成binlog补齐。


5. 数据一致性

如果采用半同步复制,且主库宕机瞬间没有发生网络超时,则HA能保证切换以后数据的一致性。但如果主库宕机瞬间,网络存在超时会导致半同步复制退化为异步复制,此时发生切换就可能丢失数据。这种情况需要业务端具备补偿机制,对数据进行补齐。但如果是MGR,不会存在数据丢失的问题。


结束语


我们结合爱奇艺多种内部监控系统、资产管理系统、CMDB、链路追踪以及混沌工程平台开发一个面向业务的应用运维平台,提供一站式服务拨测、巡检、资源使用分析、调用链路追踪以及故障演练等功能。通过混沌工程平台提供的故障注入能力,对S级业务的数据库进行攻防演练。经过不断的迭代优化,数据库的攻防演练会成为常态,通过不断的演练提升应用的可用性和安全性,真正做到有备无患。




6
资料推荐

最近有有不少老铁在后台留言说,想进大厂,但是算法不好。最近我整理了一份刷题实录,这份刷题实录,也让我进了心仪的大厂。现在开放分享给大家。希望对大家有所帮助。

任何的算法题,如同写作文一样,都有一些模板可以套用的。比如面试常考的DP(动态规划),难的是一些关键点是否能想清楚。比如你能写出动态转移方程,这题基本上就可以AC了。
整个刷题实录内容,包括LeetCode所有专题 双指针、动态规划、二分查找、贪心算法、深度优先搜索、字符串、递归、字典树、排序、链表等相关专题内容。图文并茂,附有刷题答案源码。
刷题任务的题目,是根据题目的类型来汇总的,总结了八个类别,每个类别下面也总结了5个左右的题型,帮助大家分门别类的突破,所以刷起来相对会更有重点和针对性。如果从头到尾的刷,每周按顺序刷42题,很容易让自己坚持不下来,也会觉得很枯燥。所以在制定计划的时候可以让这个计划变得更“有趣"和针对性,让它看起来更容易实现一点,才会更容易坚持。
目前上述内容已打包成完整电子书,具体获取方式如下:
  1. 扫描关注 GitHub中文社区公众号;

  2. GitHub中文社区公众号后台回复关键词「刷题」获取下载地址。



END

后台回复“面试” “资料” 领取一份干货,数百技术面试手册等你
开发者技术前线 ,汇集技术前线快讯和关注行业趋势,大厂干货,是开发者经历和成长的优秀指南。
好文点个在看吧

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存