爱奇艺MySQL高可用方案概述 _MySQL

写在前面
爱奇艺每天都为数以亿计的用户提供7*24小时不间断的视频服务。通过爱奇艺的平台，用户可以方便的获取海量、优质、高清的视频资源。但如果服务平台出现故障，会有大量的用户将无法正常播放视频，因此我们的应用服务以及数据库服务都必须具备高可用架构。
爱奇艺技术产品团队对各类应用划分了不同的重要等级，对不同重要等级的应用使用数据库服务提供了不同的 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 。
它的部署架构如下图所示：

文章插图
图1：MHA架构
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 的高可用。

文章插图
图2：HA系统架构
(1) HA Master
HA Master使用了raft的JAVA实现—copycat框架来进行Leader选举和Session监听， HA Master多机房部署。HA Master有三个重要模块：状态机、心跳模块和切换模块，状态机保存当前raft leader的地址，心跳模块和Agent保持10秒1次的心跳检查，收到Agent心跳后会更新心跳时间戳和实例状态。每次Leader重选，新的Leader会更新状态机的leader地址。Agent注册到各个HA Master的状态机内，如果状态机里的Leader地址发生了变更，则发布变更数据给每个注册的Agent ， Agent再向新的Leader发送rpc心跳。

文章插图
图3：HA架构
切换模块则负责具体的故障切换，通过定期轮训badinstance集合，对符合条件的实例进行切换。支持自动和手动两种切换方式。对于自动切换，需要在CMDB里配置好切换策略，可选同DC切换、跨DC切换还是跨地域切换。
切换流程如图所示：

文章插图
图4：故障切换流程
除了对主库支持故障切换外，也具备对从库故障切换的能力。在从库故障宕机时，通过检测故障，再操作域名的方式实现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故障切换对业务的透明。