【TiDB 4.0 新特性系列】BR 特性及原理解读

作者:李坤

BR 备份概述

备份是所有运维人员必须重视的操作,任何数据库都需要备份,TiDB 也不例外。不过一直以来 TiDB 只支持最简单的 Mydumper 备份,而没有类似物理备份的方式。 Mydumper 是逻辑备份,导出的是 SQL 语句,速度慢,占用空间大。由于备份速度慢, 备份之前还需要把 GC 时间设置得巨大,否则备份中途也会失败。在大规模的 TiDB 分布式集群上备份,随着集群越来越大,Mydumper 备份会越来越难。

TiDB 一直没有做物理备份,因为确实有难度,也没有太多可以借鉴的工业产品。物理备份通常是要扫描物理文件来实现,作为一个集群整体,虽然数据是分布的,必须要保证各个节点的外部一致性,做到全局一致的快照备份恢复。

而对应到传统的分库分表方式,单机数据库的备份在一致性上有待商榷的。比如 MySQL 常用的 Xtrabackup 物理备份工具,只能备份分库分表的一个分片,多个分片需要备份多次,多个备份集是没有关联的,不同时间点的,这样备份集在全局来看就是不一致的。

说了这么多,终于到 BR 上场了,它正是 TiDB 用户呼唤多年的类物理备份方式, BR 解决了海量数据的一致性备份,提高数据安全,注重备份恢复的效率。

BR 的功能特性

BR 做的事情,简单来说,就是通过一个 PD 地址,找到所有的 tikv-server,扫描 TiKV 的数据得到全局一致性的快照,存储下来;恢复也是通过一个 PD 地址,将备份快照恢复到 TiKV 中。

BR 是以命令行 Cli 的方式提供,用于对 TiDB 集群进行数据备份和恢复。备份的功能比较多,目前 BR 可以做到以下功能。包括

  • 整个集群的全量备份、全量恢复,
  • 指定数据库的全量备份恢复,
  • 某个数据库下指定表的全量备份恢复,
  • 支持从全量备份中恢复单表
  • 以及以上方式的增量备份

恢复目前只支持恢复到全新集群,未来也会支持在线恢复。当然,如果确认数据没有冲突,可以恢复,比如恢复一张不存在的表,否则会有数据冲突。

BR作为大集群的备份恢复工具,可以为百 T 甚至更大的集群备份。备份速度是一个非常重要的指标。BR 的优势是,在备份和恢复的操作上,是并行的,每个 tikv-server 节点同时在执行数据扫描备份。因此,如果集群变大,tikv-server 也会变多,对备份速度不会有太大的影响,当然也要考虑备份目标端的吞吐性能上限。备份的数据支持直接通过通用 S3 接口存储,也支持使用网络存储,如 NFS、NAS 等。

备份/恢复速度的指标,经过测试,在极限情况下,单个 tikv-server 可以达到 150 MB/s 。当然实际生产环境的线上备份,是不能让备份影响线上业务的,BR 也支持限速备份,可以根据自己业务的敏感度设置。


图例:不限速时,备份对集群 QPS 的影响

另外,备份安全也是一个很重要的指标,目前 BR 已经支持 CA 以及 SSL 的安全信任证书。

注意事项:

  • 暂不支持备份/恢复的断点续传
  • 备份需要保证在 GC 时间以内完成,可以调大参数 tikv_gc_life_time
  • 强烈建议使用网络存储,不要将备份集放在本地磁盘上
  • 在恢复前确定没有同名数据库/表存在

四、BR 原理和执行流程

全量备份的基本流程:

我们拥有一个 TiDB 集群。为了保证我们备份到某个“一致性快照”,首先:

  • BR 与 PD 通信,从 PD 获取当前 TS,用作 backup_ts。
  • 依照 backup_ts 来获取当时的 schema。

然后 BR 也从 PD 获取到所有 TiKV 的信息,依照用户的需求来构建需要备份的表的 Key range,使用 TiKV 提供的接口,来将备份任务“下推”到 TiKV 集群中。

在 TiKV 端,收到这个消息之后,会找到这个 Key Range 所在的所有 Regions Leader,利用 start_version 和 end_version 根据 backup_ts 获取 MVCC 中的一个快照,获取所需的键值对记录,全量备份的时候,可以忽略掉 Delete 记录。

TiKV 最终将键值对写入指定的 SST 文件中,将备份结果返回给 BR 端,由此让 BR 端可以获得一些统计信息还有 checksums,存储在 backupmeta 文件中给恢复使用,备份流程结束。

关于备份的空间占用,由于 sst 本身已经是压缩后的内容, BR 没有再进一步压缩,会按照原压缩算法写 sst,所以通常备份的结果集,与单副本数据相差不大。

图例:架构图

恢复逻辑

恢复的逻辑,简单来说就是把备份出来的 SST ,以及备份的 schema 写入到目标 TiKV 的 RocksDB 数据库中。

增量备份

用户指定 lastbackupts 之后,BR 就会备份从 lastbackupts 到 backup_ts 之间的增量数据。

需要注意的是,在全量备份和增量备份之间,或者两次增量备份之间,有可能会发生 MVCC 的 GC,因此在增量备份的时候,我们必须赶在 GC 之前备份。

通常建议备份之前,将 GC 时间调大,备份后在调整回来;另一方面,自适应的 GC 时间的提案亦已经就绪。

BR 后续规划

  1. 支持在线恢复功能
  2. 使用 SQL 执行 BR,提高易用性
  3. 支持更多的存储方式,NBU、GCS、etc …
  4. 更高的恢复速度
  5. Recover 的断点续传
  6. 自适应的 GC

六、BR 在用户的测试使用情况

在上月的 TiDB Devcon 2020 活动中,有多名用户也介绍了 BR 的使用经验,这里节选出转转和爱奇艺的工程师的使用经验。

转转-TiDB 4.0 新特性在电商行业的探索 (11’51"-13’17")
爱奇艺- TiDB 在高速增长视频业务中的应用(13’57"-15’05")

以上,是不是想赶快动手用起来呢? BR 的使用也是非常简单的,参考 「BR 备份与恢复场景示例」来使用起来吧!