备份与恢复工具 BR 简介
BR 全称为 Backup & Restore,是 TiDB 分布式备份恢复的命令行工具,用于对 TiDB 集群进行数据备份和恢复。
相比 ,BR 更适合大数据量的场景。
BR 除了可以用来进行常规备份恢复外,也可以在保证兼容性前提下用来做大规模的数据迁移。
本文介绍了 BR 的工作原理、推荐部署配置、使用限制以及几种使用方式。
BR 将备份或恢复操作命令下发到各个 TiKV 节点。TiKV 收到命令后执行相应的备份或恢复操作。
在一次备份或恢复中,各个 TiKV 节点都会有一个对应的备份路径,TiKV 备份时产生的备份文件将会保存在该路径下,恢复时也会从该路径读取相应的备份文件。
更多信息请参阅备份恢复设计方案。
备份路径下会生成以下两种类型文件:
backupmeta
文件:存储本次备份的元信息,包括备份文件数、备份文件的 Key 区间、备份文件大小和备份文件 Hash (sha256) 值backup.lock
文件:用于防止多次备份到同一目录
SST 文件命名格式
- storeID:TiKV 节点编号
- regionID:Region 编号
- regionEpoch:Region 版本号
- keyHash:Range startKey 的 Hash (sha256) 值,确保唯一性
- cf:RocksDB 的 ColumnFamily(默认为
default
或write
)
推荐部署配置
- 推荐 BR 部署在 PD 节点上。
- 推荐使用一块高性能 SSD 网盘,挂载到 BR 节点和所有 TiKV 节点上,网盘推荐万兆网卡,否则带宽有可能成为备份恢复时的性能瓶颈。
下面是使用 BR 进行备份恢复的几条限制:
- 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';
语句的开关值查询结果与备份时的查询结果相一致,才可以进行恢复。
兼容性
BR 和 TiDB 集群的兼容性问题分为以下两方面:
- BR 部分版本和 TiDB 集群的接口不兼容
- 某些功能在开启或关闭状态下,会导致 KV 格式发生变化,因此备份和恢复期间如果没有统一开启或关闭,就会带来不兼容的问题
下表整理了会导致 KV 格式发生变化的功能。
在上述功能确保备份恢复一致的前提下,BR 和 TiKV/TiDB/PD 还可能因为版本内部协议不一致/接口不一致出现不兼容的问题,因此 BR 内置了版本检查。
版本检查
BR 内置版本会在执行备份和恢复操作前,对 TiDB 集群版本和自身版本进行对比检查。如果大版本不匹配(比如 BR v4.x 和 TiDB v5.x 上),BR 会提示退出。如要跳过版本检查,可以通过设置 --check-requirements=false
强行跳过版本检查。
需要注意的是,跳过检查可能会遇到版本不兼容的问题。BR 和 TiDB 各版本兼容情况如下表所示:
备份和恢复 mysql
系统库下的表数据(实验特性)
如果你希望将系统表(如 )的数据恢复到系统库 mysql
中,可以设置 来过滤表名 (-f "mysql.usertable1"
)。完成设置后,系统库下的表数据会恢复到临时库中,然后通过对临时库表进行重命名的方式恢复到系统库。
由于技术原因,以下系统表不能被正确恢复。即使你指定了 -f "mysql.*"
,以下表也不会被恢复:
- 统计信息相关的表:”stats_buckets”,”stats_extended”,”stats_feedback”,”stats_fm_sketch”,”stats_histograms”,”stats_meta”,”stats_top_n”
运行 BR 的最低机型配置要求如下:
一般场景下(备份恢复的表少于 1000 张),BR 在运行期间的 CPU 消耗不会超过 200%,内存消耗不会超过 4 GB。但在备份和恢复大量数据表时,BR 的内存消耗可能会上升到 4 GB 以上。在实际测试中,备份 24000 张表大概需要消耗 2.7 GB 内存,CPU 消耗维持在 100% 以下。
最佳实践
下面是使用 BR 进行备份恢复的几种推荐操作:
- 推荐在业务低峰时执行备份操作,这样能最大程度地减少对业务的影响。
- BR 支持在不同拓扑的集群上执行恢复,但恢复期间对在线业务影响很大,建议低峰期或者限速 (
rate-limit
) 执行恢复。 - BR 备份最好串行执行。不同备份任务并行会导致备份性能降低,同时也会影响在线业务。
- BR 恢复最好串行执行。不同恢复任务并行会导致 Region 冲突增多,恢复的性能降低。
- 推荐在
-s
指定的备份路径上挂载一个共享存储,例如 NFS。这样能方便收集和管理备份文件。 - 在使用共享存储时,推荐使用高吞吐的存储硬件,因为存储的吞吐会限制备份或恢复的速度。
- BR 默认会分别在备份、恢复完成后,进行一轮数据校验,将文本数据同集群数据比较,来保证正确性。在迁移场景下,为了减少迁移耗时,推荐备份时关闭校验(
--checksum=false
),只在恢复时开启校验。
使用方式
目前支持以下几种方式来运行 BR 工具,分别是通过 SQL 语句、命令行工具或在 Kubernetes 环境下进行备份恢复。
通过 SQL 语句
TiDB 支持使用 SQL 语句 和 进行备份恢复。如果要查看备份恢复的进度,你可以使用 语句。
通过命令行工具
TiDB 支持使用 BR 命令行工具进行备份恢复(需)。关于 BR 命令行工具的具体使用方法,请参阅使用备份与恢复工具 BR。
在 Kubernetes 环境下
目前支持使用 BR 工具备份 TiDB 集群数据到兼容 S3 的存储、Google Cloud Storage 以及持久卷,并作恢复: