大家好，我是哪吒。
爱奇艺每天都为数以亿计的用户提供7x24小时不间断的视频服务。通过爱奇艺的平台，用户可以方便地获取海量、优质、高清的视频资源。但如果服务平台出现故障，会有大量的用户将无法正常播放视频，因此我们的应用服务以及数据库服务都必须具备高可用架构。
爱奇艺技术产品团队对各类应用划分了不同的重要等级，对不同重要等级的应用使用数据库服务提供了不同的SLA保障。比如S级应用RTO控制在分钟级别的保障；对A级应用RTO在10分钟级别的保障等。本文将主要介绍我们的MySQL高可用实现方案。
一、基于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的高可用方案。
二、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故障切换对业务的透明。
三、HA的选主规则
HA需要一套复杂的选主规则，用以适配我们复杂的部署环境，选主规则如下：
- 排除在bad slaves里的slave
- 选择所有latest slaves优先级最高的candidate master
- 如果从库没有设置优先级，选出所有非bad slaves的slave
- 根据切换策略，依次选择同DC→同region→跨region的slave
- 对满足条件的从库，排除从库所在机器Master个数和Slave个数太多的salve，在剩下的slave中选择机器剩余磁盘空间最大的slave
通过以上规则，选出一个最优的主进行切换。如果没有满足条件的slave，则会通过电话告警的方式通知DBA进行人工干预。
四、补全diff binlog
在Master切换过程中，会存在3种类型的diff binlog：
- 从库io thread接收到的relay log不完整，不是一个完整的事务或完整的binlog event
- lastest slave与其他slave存在的diff relay log
- 如果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补齐。
五、数据一致性
如果采用半同步复制，且主库宕机瞬间没有发生网络超时，则HA能保证切换以后数据的一致性。但如果主库宕机瞬间，网络存在超时会导致半同步复制退化为异步复制，此时发生切换就可能丢失数据。这种情况需要业务端具备补偿机制，对数据进行补齐。但如果是MGR，不会存在数据丢失的问题。
六、总结
我们结合爱奇艺多种内部监控系统、资产管理系统、CMDB、链路追踪以及混沌工程平台开发一个面向业务的应用运维平台，提供一站式服务拨测、巡检、资源使用分析、调用链路追踪以及故障演练等功能。通过混沌工程平台提供的故障注入能力，对S级业务的数据库进行攻防演练。经过不断的迭代优化，数据库的攻防演练会成为常态，通过不断的演练提升应用的可用性和安全性，真正做到有备无患。
七、《MySQL高可用解决方案――从主从复制到InnoDB Cluster架构》
购书传送门
1、作者
徐轶韬，甲骨文公司MySQL解决方案首席工程师。为中国金融、政府、航空运输等行业的MySQL用户提供相关产品的售前咨询、企业级产品介绍、解决方案服务，以及推广和普及MySQL数据库在社区的使用。公众号“MySQL解决方案工程师”的运营者和内容作者。“3306π”开源软件社区活动出品人，“墨天轮”社区2020年度十大突出贡献人物。
2、内容简介
本书对MySQL官方提供的高可用解决方案逐一进行介绍，详细阐述每种方案的原理、架构、优缺点及适用场景，并配合演示说明，帮助读者快速理解相关内容。与其他MySQL高可用相关图书不同，本书专注于MySQL官方团队提供的解决方案，包括MySQL主从复制、MySQL ReplicaSet、组复制、InnoDB Cluster及InnoDB ClusterSet等相关内容。此外，本书还介绍了MySQL 8.0的部分内容，包括文档存储、MySQL Shell及MySQL Router等。附录部分介绍了企业版监控、企业版备份等MySQL官方工具，以及克隆插件和虚拟机环境VirtualBox，使读者可以更加全面地了解MySQL的生态和工具。通过本书，MySQL数据库开发人员、MySQL数据库管理人员和架构师可以了解MySQL当前全部的产品特性和高可用解决方案，获知每种方案的详细内容，并能够将高可用解决方案灵活运用到实际的生产解决方案中。本书面向的读者对象包括MySQL的初学者、数据库架构师、DBA、相关软件开发人员，以及组织内部的IT负责人。
3、送 3 本《一本书讲透Elasticsearch：原理、进阶与工程实践》
4、 学习传送门 >>> 哪吒编程，陪伴学习，共同优秀
每天分享Java硬核干货，包含Java基础、数据库、SSM、SpringBoot、微服务、设计模式、算法等系列文章。一起学习打卡，遇到问题，发到群里，一起讨论学习，比一个人学习效率高的多。
坚持每日学习打卡，养成持续学习、持续成长的好习惯。
成功秘诀只有一个，那就是卷，督促和鞭策自己，永不放弃。
