写在前面
爱奇艺每天都为数以亿计的用户提供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虽然已经比较成熟，但也存在一些的缺点：
另外我们的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故障切换对业务的透明。
图5：MGR高可用方案
3. HA的选主规则
HA需要一套复杂的选主规则，用以适配我们复杂的部署环境，选主规则如下：
排除在bad slaves里的slave
选择所有latest slaves优先级最高的candidate master
如果从库没有设置优先级，选出所有非bad slaves的slave
根据切换策略，依次选择同DC->同region->跨region的slave。
对满足条件的从库，排除从库所在机器Master个数和Slave个数太多的salve，在剩下的slave中选择机器剩余磁盘空间最大的slave。
通过以上规则，选出一个最优的主进行切换。如果没有满足条件的slave，则会通过电话告警的方式通知DBA进行人工干预。
4. 补全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的恢复顺序如图所示：
图6：数据恢复步骤
如果是使用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级业务的数据库进行攻防演练。经过不断的迭代优化，数据库的攻防演练会成为常态，通过不断的演练提升应用的可用性和安全性，真正做到有备无患。
技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
长按二维码 关注「高可用架构」公众号
