B 站在数据库故障治理方面做了啥？

上面讲述了常见的数据库故障，下面我们来说说如何从数据库架构设计上来规避故障，这里会结合 B 站的一些实践来跟大家分享。  

1、高可用
 

高可用（High Availability）是系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。所以在做数据架构设计时一定要考虑 HA 能力，无论是选用集群模式 (MGR、PXC 等)，或是使用传统主从复制加上其他高可用组件 (Orchestrator、MySQL Replication Manager、MHA 等)，都可以帮我们在实例不可用时把损失最小化。

 

2、扩容

扩容一般分为垂直扩容和水平扩容两种，对于传统 MySQL 来讲，垂直扩容的收益比通常不高， 而基于其本身状态的水平扩容又很难做到快速，所以如何做应急扩容一直是业内比较头疼的问题。 这时候引入云原生数据库是一个不错的选择，业内的云原生数据库大都进行了存储计算分离改造，对于计算层可以通过 k8s 的 HPA 能力进行快速扩容，而存储层则依赖于底层共享存储或者分布式存储也有不同的扩容方式。 在 B 站我们大量引入了 TiDB， 在一些适合弹性伸缩的场景下有不错的收益。

• 垂直扩容：增大 buffer pool、 cpu 限制等配额，需要平台侧完善 Quota 管理和变更能力。
• 水平扩容：对于 MySQL 来讲， 应急快速水平扩容只能用于读负载，我们会有一些异地机房的实例，一般情况下用作灾备以及离线用途， 在极端场景下可以通过平台操作一键接入读负载池；对于 TiDB 来讲，我们把计算节点放入 k8s，通过 k8s 的 HPA 能力进行水平弹性伸缩。

3、多活建设

多活是高可用的升级版，一般分为异地灾备、同城多活、异地多活、两地三中心、三地五中心等不同的架构设计。（回顾传送门： B 站 SRE 负责人亲述 713 故障后的多活容灾建设  ）

• 异地灾备： 当主机房的实例全部不可用时进行切换，一般是由高可用组件触发切换，高可用组件本身应该是一个分布式跨机房的架构。 比如在 B 站，我们的高可用组件是三机房投票决策的，同时应当注意避免跨机房专线异常造成的误判以及误切换熔断策略。

• 同城双活： 主库在同城某一个 zone，从库则分布在同城的不同 zone，每个 zone 的读请求实现单元内闭环，写请求则跨 zone 访问对应的主库，需要在数据库 proxy 或者 sdk 层实现请求路由的自动感知和判断。

• 异地多活： 依赖业务单元化改造，读写请求全部单元内闭环，要求整体架构具备单元流量调度以及异常流量矫正的能力。属于同一个 global cluster 的集群间通过 DTS 进行双向数据同步，DTS 层需要解决数据回环问题以及冲突检测机制，对于数据冲突的场景提供不同的策略，比如覆盖策略、暂停同步策略等。对于冲突数据也可以考虑写入消息队列，便于业务侧矫正处理，同时应具备全局发号器主键填充能力，避免双向同步的主键冲突。

• 两地三中心: 可以简单理解为同城多活加上异地灾备架构，其中灾备机房应当根据灾难承受程度和数据保护程度来权衡地理距离。

上述几种架构中， 异地灾备和同城双活的读流量通过数据库接入层管控进行切流，比如 proxy、sdk 的元数据管理，写流量则以数据库高可用组件的切换作为切流手段；而异地多活架构下的切流方案一般是通过应用上层切换，比如 CDN、SLB、应用网关等实现。  

4、Proxy 数据库代理

数据库代理（又名 proxy）是位于数据库服务和应用服务之间的网络代理服务，用于代理应用服务访问数据库时的所有请求。 数据库代理一般包含以下核心功能：

• 读写分离

• 拦截

• 限流

• 熔断

通过对 Proxy 的大量使用，我们可以实现针对某个数据库、某个服务、某类 SQL 指纹进行拦截，限流、熔断来阻止某些异常流量打崩数据的场景。  

5、慢查询预警

慢查询是导致数据库性能下降中少数具有可预测性的内容，为此我们专门建设了慢查询预警体系，这套体系包含日志采集、流式处理、结果分析、告警及其他操作（如：自愈等）。 慢查询预警系统的采集样本是过去 7 天同时间段前后十分钟，和当天前 10 分钟数据，通过多次线性回归，我们实现了对偶发性的抖动的过滤 ，不同业务级别环比倍数、持续性增长（未到阈值倍数，但持续增长或存在）慢查询的预警，并且基于规则引擎实现自定义处理。  

6、一个具体的小案例分享

下面分享一个针对复制 bug 的处理过程。

• 问题背景：

业务研发收到多起创建预约的问题反馈，如：创建预约后拉取不到预约详情

查询从库未读取到相关数据

• 核心处理步骤：

DBA 先检查从库复制状态，未发现复制异常；使用 show global variables like '% gtid%' 检查 gtid，发现 gtid_binlog_pos 不发生变化，故判断可能是 mariadb 多线程复制 bug 导致数据不同步；与业务研发同事沟通后，通过修改 proxy 配置将所有流量切换到主库，同时切换 canal 到主库，最终因复制 bug 导致的业务影响很快被控制下来。

• 后续优化：

• 增加心跳表以规避复制 bug 导致的常规复制监控不可用。

• 基于高可用、心跳表、数据库负载（QPS、CPU、网络等）等信息，实现在从库异常情况下将流量切换到主库和数据订阅的数据源切换到主库。

• 说明：

触发该复制 bug 后，使用 show slave status 看不到复制状态的任何异常，下图是当时的监控：