作为mysql数据的分布式大型集群替代，TiDB被越来越多企业在生产中使用。作为一个超大的数据库集群，对TB集合数据的备份和还原是一个难点和挑战。最近TiDB官方在4.0 RC版本中新增加了一个数据备份和还原工具BR，用来实现对超大规模（10TB）数据的高速备份和还原，可以将备份还原速度提高到1GB/s甚至更高。本文虫虫就给大家介绍这个高性能备份还原工具BR。

概述

TiDB是一个与MySQL高度兼容的开放源代码的NewSQL数据库，支持混合事务处理/分析处理（HTAP）工作负载。对于大型TiDB集群而言，备份和还原长期以来一直是一个具有挑战性的问题。由于数据分布在不同的节点中，因此TiDB没有一致的物理快照。

Mysdumper和myloader是MySQL数据中最常用的数据备份和还原工具。TiDB和MySQL协议兼容，所以TiDB中也使用他们进行备份和还原。但是对超大的TiDB集群mydumper不适用存在严重的短板：mydumper无法合理利用群集资源来提高备份速度。因此会严重影响应用程序请求甚至会导致TiDB的内存不足（OOM）错误。

根据实践中的测试数据。TiDB Loader恢复1 TB的数据大约需要19个小时。很明显，这样的速度不能满足日常数据高效恢复的需求。

因此，尽管可以使用mydumper和Loader做数据备份和恢复，但他们在对待大规模数据时候，已经完全不适应生产需求。因此，TiDB新引入了备份和还原工具BR。

主要原理

BR是用于快速分布式备份和还原TiDB群集数据的命令行工具。与mydumper和Loader相比，BR更适合于TB级别的大规模TiDB数据集。

TiDB的经典体系架构如下图

在TiDB平台内部，主要组件如下：

TiDB Server是无状态SQL层。

TiKV服务器是数据持久化的分布式事务键值存储层。

Placement Driver（PD）是服务器管理群集。

数据备份

BR的主要实现：水平可伸缩性和强一致性。

1、执行数据备份命令时，会按顺序执行以下操作：

首先从 PD 获取相关元数据信息：

当前的 TS 作为备份快照的时间点

集群的 TiKV 节点信息

2、根据这些数据，在内部启动一个新实例，获取对应TS的数据库或表信息，过程中会忽略系统数据库information_schema，performance_schema和mysql。

3、备份子命令令根据需求执行如下操作：

全量备份：BR 遍历全部库表，并且根据这些表构建需要备份的 KV Range

单表备份：BR 根据该表构建需要备份的KV Range

4、最后，BR 将需要备份的KV Range收集后，构造完整的备份请求分发给集群内的 TiKV 节点。

数据恢复

对数据库恢复，BR按顺序执行以下任务：

1、解析备份路径下的backupMeta文件，根据解析出来的库表信息，新创建一个实例在新集群创建对应的库表。

2、对解析出来的SST文件，进行表聚合。

3、根据Key Range进行预切分 Region，使得各个Region至少对应一个SST文件。

4、遍历要恢复的每一张表和其对应的SST文件。

5、找到Region，发送下载文件的请求到对应的TiKV节点，下载成功后，发送加载请求。

6、TiKV 收到加载SST文件的请求后，利用 Raft 机制保证加载 SST 数据的强一致性。

7、在加载成功后，下载下来的 SST 文件会被异步删除。

完成恢复操作后，BR会对恢复后的数据校验计算，和备份数据进行对比。

BR使用初步

BR命令是由子命令、选项和参数组成的。一个典型的命令如下：

br backup full --pd "${PDIP}:2379" -s "local:///tmp/backup"

子命令不带-和--的字符（如本例中的backup，full）。选项即以-或者--开头的字符（本例中的-s或者等效的—storage，--pd）。参数即子命令或选项字符后紧跟的、并传递给命令和选项的字符，一般要用引号括住（本例中的

常见子命令

BR 命令由多层构成。BR支持backup、restore 和 version 三个子命令:

backup 用于备份TiDB集群

restore 用于恢复TiDB集群

version 用于显示BR版本信息

以上三个子命令可能还包含下面的一些子命令：

full：可用于全库备份或恢。

db：可用于备份或恢复集群中的特定的数据库。

table：可用于备份或恢复集群中特定的单张表。

常用选项

--pd：用于连接的选项，表示PD服务地址。

-h/--help：获取所有命令和子命令的使用帮助。比如 br backup --help。

--ca：指定 PEM 格式的受信任CA的证书文件路径。

--cert：指定 PEM 格式的SSL证书文件路径。

--key：指定 PEM 格式的SSL证书密钥文件路径。

--status-addr：BR 向Prometheus提供统计数据的监听地址。

实例：

备份全部集群数据：

br backup full \

--pd "${PDIP}:2379" \

--storage "local:///tmp/backup" \

--ratelimit 120 \

--concurrency 4 \

--log-file backupfull.log

所有集群数据会被备份到各自TiKV节点的 /tmp/backup 路径，同时备份的元数据文件backupmeta。--ratelimit 和 --concurrency 选项限制了每个TiKV执行备份任务的速度上限（单位 MiB/s）和并发数上限。--log-file 选项指定把 BR 的 log 写到 backupfull.log 文件中。

备份期间有进度条在终端中显示。当进度条前进到 100% 时，说明备份已完成。。进度条效果如下：

Full Backup <----------/...............................................> 19.02%.

备份单个库

br backup db \

--pd "${PDIP}:2379" \

--db test \

--storage "local:///tmp/backup" \

--ratelimit 120 \

--concurrency 4 \

--log-file backuptable.log

备分单个表

br backup table \

--pd "${PDIP}:2379" \

--db test \

--table usertable \

--storage "local:///tmp/backup" \

--ratelimit 120 \

--concurrency 4 \

--log-file backuptable.log

恢复操作

br restore full \

--pd "${PDIP}:2379" \

--storage "local:///tmp/backup" \

--concurrency 128 \

--log-file restorefull.log

官方基准测试（10TB）

官方提供了BR备份恢复的基准测试，其结果如下图所示

对10 TB数据的群集，BR能够以2.7 GB/s的平均速度（五个TiDB实例的平均548 MB/s）。测试期间的最大速度略高于4 GB/s，每个实例的最大备份速度在770 MB/s至866 MB/s之间。

对10 TB数据集群，恢复操作平均速度为0.7 GB/s，五个TiDB实例的平均速度为150 MB/s。在测试过程中，BR的最大存储速度约为1.2 GB/s，每个实例的最大恢复速度为247 MB/s至268 MB/s。

备份速度

备份了两个表。在下图中，绿色曲线代表所有TiKV实例的总体备份速度，其他曲线代表每个实例的备份速度。

在11:15和11:28，备份索引数据。由于索引条目很短，因此备份速度会降低。

恢复速度

备份后，还原了两个表。绿色曲线代表总体还原速度，其他曲线代表每个TiKV实例的还原速度。

BR将还原任务分为多个子任务，然后按顺序执行这些子任务。这样我们可以看到图中的故障。它们可能是需要进一步优化的潜在问题。

在1:00和1:15，将还原索引数据。因为索引条目很短，所以还原速度会降低。