MySQL高可用解决方案――从主从复制到InnoDB Cluster架构_mysql高可用解决方案――从主从复制到innodb cluster架构 pdf

2024送书福利正式起航 关注「哪吒编程」，提升Java技能 文末送5本《MySQL高可用解决方案――从主从复制到InnoDB Cluster架构》

大家好，我是哪吒。

爱奇艺每天都为数以亿计的用户提供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需要一套复杂的选主规则，用以适配我们复杂的部署环境，选主规则如下：

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进行人工干预。

四、补全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补齐。

五、数据一致性

如果采用半同步复制，且主库宕机瞬间没有发生网络超时，则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：原理、进阶与工程实践》

关于MySQL，想必每个人都有自己的心得体会，欢迎大家在留言区分享，今天就给大家送《MySQL高可用解决方案》了 1楼、2楼、5楼、10楼可分别获得一本 评论最走心人士，额外再送一本 活动截止时间：2024-3-27 21:00:00 哪吒会在朋友圈公布中奖名单

4、 学习传送门 >>> 哪吒编程，陪伴学习，共同优秀

每天分享Java硬核干货，包含Java基础、数据库、SSM、SpringBoot、微服务、设计模式、算法等系列文章。一起学习打卡，遇到问题，发到群里，一起讨论学习，比一个人学习效率高的多。

坚持每日学习打卡，养成持续学习、持续成长的好习惯。

成功秘诀只有一个，那就是卷，督促和鞭策自己，永不放弃。