爱奇艺 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 故障切换对业务的透明。

图 5：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 的恢复顺序如图所示：

图 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 级业务的数据库进行攻防演练。经过不断的迭代优化，数据库的攻防演练会成为常态，通过不断的演练提升应用的可用性和安全性，真正做到有备无患。

本文转载自公众号爱奇艺技术产品团队（ID：iQIYI-TP）。

原文链接：

爱奇艺MySQL高可用方案概述