备份与恢复工具 BR 简介

相比，BR 更适合大数据量的场景。

本文介绍了 BR 的工作原理、推荐部署配置、使用限制以及几种使用方式。

BR 将备份或恢复操作命令下发到各个 TiKV 节点。TiKV 收到命令后执行相应的备份或恢复操作。

在一次备份或恢复中，各个 TiKV 节点都会有一个对应的备份路径，TiKV 备份时产生的备份文件将会保存在该路径下，恢复时也会从该路径读取相应的备份文件。

更多信息请参阅。

备份路径下会生成以下两种类型文件：

SST 文件：存储 TiKV 备份下来的数据信息
backupmeta 文件：存储本次备份的元信息，包括备份文件数、备份文件的 Key 区间、备份文件大小和备份文件 Hash (sha256) 值

SST 文件命名格式

storeID：TiKV 节点编号
regionID：Region 编号
regionEpoch：Region 版本号
keyHash：Range startKey 的 Hash (sha256) 值，确保唯一性
cf：RocksDB 的 ColumnFamily（默认为或 write）

推荐 BR 部署在 PD 节点上。
推荐使用一块高性能 SSD 网盘，挂载到 BR 节点和所有 TiKV 节点上，网盘推荐万兆网卡，否则带宽有可能成为备份恢复时的性能瓶颈。

使用限制

下面是使用 BR 进行备份恢复的几条限制：

BR 只支持在 TiDB v3.1 及以上版本使用。
BR 恢复到 TiCDC / Drainer 的上游集群时，恢复数据无法由 TiCDC / Drainer 同步到下游。
BR 只支持在 new_collations_enabled_on_first_bootstrap 开关值相同的集群之间进行操作。这是因为 BR 仅备份 KV 数据。如果备份集群和恢复集群采用不同的排序规则，数据校验会不通过。所以恢复集群时，你需要确保 select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME='new_collation_enabled'; 语句的开关值查询结果与备份时的查询结果相一致，才可以进行恢复。
- 对于 v3.1 集群，TiDB 尚未支持 new collation，因此可以认为 new collation 未打开
- 对于 v4.0 集群，请通过查看 new collation 是否打开。
  
  例如，数据备份在 v3.1 集群。如果恢复到 v4.0 集群中，查询恢复集群的 new_collation_enabled 的值为 true，则说明创建恢复集群时打开了 new collation 支持的开关。此时恢复数据，可能会出错。

运行 BR 的最低机型配置要求如下：

一般场景下（备份恢复的表少于 1000 张），BR 在运行期间的 CPU 消耗不会超过 200%，内存消耗不会超过 1 GB。但在备份和恢复大量数据表时，BR 的内存消耗可能会上升到 3 GB 以上。在实际测试中，备份 24000 张表大概需要消耗 2.7 GB 内存，CPU 消耗维持在 100% 以下。

最佳实践

推荐在业务低峰时执行备份操作，这样能最大程度地减少对业务的影响。
BR 备份最好串行执行。不同备份任务并行会导致备份性能降低，同时也会影响在线业务。
BR 恢复最好串行执行。不同恢复任务并行会导致 Region 冲突增多，恢复的性能降低。
推荐在指定的备份路径上挂载一个共享存储，例如 NFS。这样能方便收集和管理备份文件。
在使用共享存储时，推荐使用高吞吐的存储硬件，因为存储的吞吐会限制备份或恢复的速度。

目前支持以下几种方式来运行 BR 工具，分别是通过 SQL 语句、命令行工具或在 Kubernetes 环境下进行备份恢复。

通过 SQL 语句

在 v4.0.2 及以上版本的 TiDB 中，支持直接通过 SQL 语句进行备份恢复，具体使用示例见：

Restore 语法

通过命令行工具

在 v3.1 以上的 TiDB 版本中，支持通过命令行工具进行备份恢复。

首先需要下载一个 BR 工具的二进制包，详见下载链接。

通过命令行工具进行备份恢复的具体操作见。

在 Kubernetes 环境下

目前支持使用 BR 工具备份 TiDB 集群数据到兼容 S3 的存储、Google Cloud Storage 以及持久卷，并作恢复：

注意：

BR 备份与恢复场景示例

BR 工具简介