概述
TiDB 支持使用 br 工具进行备份恢复。
安装方法可以使用 TiUP 在线安装:
tiup install br
使用备份恢复功能的部署要求如下:
- BR、TiKV 节点和备份存储系统需要提供大于备份速度的的网络带宽。当集群特别大的时候,备份和恢复速度上限受限于备份网络的带宽。
- 备份存储系统还需要提供足够的写入/读取性能 (IOPS),否则它有可能成为备份恢复时的性能瓶颈。
- TiKV 节点需要为备份准备至少额外的两个 CPU core 和高性能的磁盘,否则备份将对集群上运行的业务产生影响。
- 推荐 br 工具运行在 8 核+/16 GB+ 的节点上。
备份目录的用户所属组是 tidb.tidb,
tikv节点的备份目录下存放的是实际备份的数据,而pd节点存放的是备份的元数据。
注:
不支持在一个集群上同时运行多个数据备份任务。
不支持在一个集群上同时运行快照备份任务和数据恢复任务。
TiDB 快照备份
快照备份是集群全量备份的一种实现。
它基于 TiDB 的MVCC实现,将指定快照包含的所有数据备份到目标存储中。
备份下来的数据大小约等于集群(压缩后的)单副本数据大小。
备份完成之后,可以在一个空集群或不存在数据冲突(相同 schema 或 table)的集群执行快照备份恢复,将集群恢复到快照备份时的数据状态,同时恢复功能会依据集群副本设置恢复出多副本。
快照备份命令:
tiup br backup full --pd "${PD_IP}:2379" \
--backupts '2022-09-08 13:30:00 +08:00' \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" \
--ratelimit 128 \
以上命令中:
--backupts
:快照对应的物理时间点,格式可以是 TSO 或者时间戳,例如400036290571534337
或者2018-05-11 01:42:23 +08:00
。如果该快照的数据被垃圾回收 (GC) 了,那么tiup br backup
命令会报错并退出。使用日期方式备份时,建议同时指定时区,否则 br 默认使用本地时间构造时间戳,可能导致备份时间点错误。如果你没有指定该参数,那么 br 会选取备份开始的时间点所对应的快照。--storage
:数据备份到的存储地址。快照备份支持以 Amazon S3、Google Cloud Storage、Azure Blob Storage 为备份存储,以上命令以 Amazon S3 为示例。详细存储地址格式请参考外部存储服务的 URI 格式。--ratelimit
:每个TiKV备份数据的速度上限,单位为 MiB/s。
查看详细使用帮助:
tiup br backup full --help
我们使用测试环境验证备份单库:
cd /home/tidb/.tiup/bin
./tiup br backup db --db pingcap_test01 --pd "10.0.8.88:2379" --storage "/backup/tidb_backup" --ratelimit 128
在快照备份过程中,终端会显示备份进度条。在备份完成后,会输出备份耗时、速度、备份数据大小等信息:
Starting component br: /home/tidb/.tiup/components/br/v8.1.1/br backup db --db pingcap_test01 --pd 10.0.8.88:2379 --storage /backup/tidb_backup --ratelimit 128
Detail BR log in /tmp/br.log.2024-10-21T15.53.14+0800
[2024/10/21 15:53:14.721 +08:00] [WARN] [backup.go:311] ["setting `--ratelimit` and `--concurrency` at the same time, ignoring `--concurrency`: `--ratelimit` forces sequential (i.e. concurrency = 1) backup"] [ratelimit=134.2MB/s] [concurrency-specified=4]
Database Backup <------------------------------------------------------------------------------------------------------------------------------------> 100.00%
Checksum <-------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
[2024/10/21 15:53:18.912 +08:00] [INFO] [collector.go:77] ["Database Backup success summary"] [total-ranges=2] [ranges-succeed=2] [ranges-failed=0] [backup-checksum=9.930648ms] [backup-fast-checksum=5.479934ms] [backup-total-ranges=2] [backup-total-regions=2] [total-take=4.19936762s] [total-kv=2] [total-kv-size=88B] [average-speed=20.96B/s] [backup-data-size(after-compressed)=3.288kB] [Size=3288] [BackupTS=453377312893173767]
备份路径下会生成以下两种类型文件:
- SST 文件:存储 TiKV 备份下来的数据信息
- backupmeta 文件:存储本次备份的元信息,包括备份文件数、备份文件的 Key 区间、备份文件大小和备份文件 Hash (sha256) 值
查询快照备份的时间点信息
查看某个快照备份对应的快照物理时间点:
tiup br validate decode --field="end-version" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" | tail -n1
测试环境里执行:
tiup br validate decode --field="end-version" --storage "/backup/tidb_backup"
输出结果为:
Starting component br: /home/tidb/.tiup/components/br/v8.1.1/br validate decode --field=end-version --storage /backup/tidb_backup
Detail BR log in /tmp/br.log.2024-10-21T16.46.41+0800
453377312893173767
恢复快照备份数据
查看详细使用帮助:
tiup br restore full --help
恢复到目标集群:
tiup br restore full --pd "${PD_IP}:2379" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"
测试环境恢复:
./tiup br restore full --pd "10.0.8.88:2379" --storage "/backup/tidb_backup"
恢复单库:
./tiup br restore db --db pingcap_test01 --pd "10.0.8.88:2379" --storage "/backup/tidb_backup"
恢复单表:
./tiup br restore table --db pingcap_test01 --table tab_tidb --pd "10.0.8.88:2379" --storage "/backup/tidb_backup"
使用表库过滤功能恢复部分数据:
./tiup br restore full --pd "10.0.8.88:2379" --filter 'pingcap_test01.tab_tidb' --storage "/backup/tidb_backup"
测试打印结果为:
Starting component br: /home/tidb/.tiup/components/br/v8.1.1/br restore full --pd 10.0.8.88:2379 --filter pingcap_test01.tab_tidb --storage /backup/tidb_backup
Detail BR log in /tmp/br.log.2024-10-21T17.18.32+0800
Full Restore <---------------------------------------------------------------------------------------------------------------------------------------> 100.00%
[2024/10/21 17:18:37.004 +08:00] [INFO] [collector.go:77] ["Full Restore success summary"] [total-ranges=3] [ranges-succeed=3] [ranges-failed=0] [split-region=1.361125ms] [restore-ranges=2] [total-take=4.679754552s] [restore-data-size(after-compressed)=3.288kB] [Size=3288] [BackupTS=453377312893173767] [RestoreTS=453378654244438017] [total-kv=2] [total-kv-size=88B] [average-speed=18.8B/s]
再检查数据库相应数据已恢复。
性能与影响
快照备份的性能与影响
TiDB 备份功能对集群性能(事务延迟和 QPS)有一定的影响,但是可以通过调整备份的线程数 backup.num-threads
,以及增加集群配置,来降低备份对集群性能的影响。
为了更加具体说明备份对集群的影响,下面列举了多次快照备份测试结论来说明影响的范围:
- (使用 5.3 及之前版本)在默认配置下,单 TiKV 存储节点上备份线程数量是节点 CPU 总数量的 75% 时,QPS 会下降到备份之前的 35% 左右。
- (使用 5.4 及以后版本)单 TiKV 存储节点上备份的线程数量不大于
8
、集群总 CPU 利用率不超过 80% 时,备份任务对集群(无论读写负载)影响最大在 20% 左右。 - (使用 5.4 及以后版本)单 TiKV 存储节点上备份的线程数量不大于
8
、集群总 CPU 利用率不超过 75% 时,备份任务对集群(无论读写负载)影响最大在 10% 左右。 - (使用 5.4 及以后版本)单 TiKV 存储节点上备份的线程数量不大于
8
、集群总 CPU 利用率不超过 60% 时,备份任务对集群(无论读写负载)几乎没有影响。
你可以通过如下方案手动控制备份对集群性能带来的影响。但是,这两种方案在减少备份对集群的影响的同时,也会降低备份任务的速度。
- 使用
--ratelimit
参数对备份任务进行限速。请注意,这个参数限制的是把备份文件存储到外部存储的速度。计算备份文件的大小时,请以备份日志中的backup data size(after compressed)
为准。设置--ratelimit
后,为了避免任务数过多导致限速失效,br 的concurrency
参数会自动调整为 1。 - 调节 TiKV 配置项
backup.num-threads
,限制备份任务使用的工作线程数量。内部测试数据表明,当备份的线程数量不大于8
、集群总 CPU 利用率不超过 60% 时,备份任务对集群(无论读写负载)几乎没有影响。
通过限制备份的线程数量可以降低备份对集群性能的影响,但是这会影响到备份的性能,以上的多次备份测试结果显示,单 TiKV 存储节点上备份速度和备份线程数量呈正比。在线程数量较少的时候,备份速度约为 20 MiB/线程数。例如,单 TiKV 节点 5 个备份线程可达到 100 MiB/s 的备份速度。
快照恢复的性能与影响
-
TiDB 恢复的时候会尽可能打满 TiKV CPU、磁盘 IO、网络带宽等资源,所以推荐在空的集群上执行备份数据的恢复,避免对正在运行的业务产生影响。
-
备份数据的恢复速度与集群配置、部署、运行的业务都有比较大的关系。在内部多场景仿真测试中,单 TiKV 存储节点上备份数据恢复速度能够达到 100 MiB/s。在不同用户场景下,快照恢复的性能和影响应以实际测试结论为准。
-
BR 提供了粗粒度的 Region 打散算法,用于提升大规模 Region 场景下的 Region 恢复速度。该算法通过命令行参数
--granularity="coarse-grained"
控制,并默认启用。在这个方式下每个 TiKV 节点会得到均匀稳定的下载任务,从而充分利用每个 TiKV 节点的所有资源实现并行快速恢复。在实际案例中,大规模 Region 场景下,集群快照恢复速度最高提升约 3 倍。使用示例如下:
br restore full \ --pd "${PDIP}:2379" \ --storage "s3://${Bucket}/${Folder}" \ --s3.region "${region}" \ --granularity "coarse-grained" \ --send-credentials-to-tikv=true \ --log-file restorefull.log
- 从 v8.0.0 起,
br
命令行工具新增--tikv-max-restore-concurrency
参数,用于控制每个 TiKV 节点的最大 download 和 ingest 文件数量。此外,通过调整此参数,可以控制作业队列的最大长度(作业队列的最大长度 = 32 * TiKV 节点数量 *--tikv-max-restore-concurrency
),进而控制 BR 节点的内存消耗。
通常情况下,
--tikv-max-restore-concurrency
会根据集群配置自动调整,无需手动设置。如果通过 Grafana 中的 TiKV-Details > Backup & Import > Import RPC count 监控指标发现 download 文件数量长时间接近于 0,而 ingest 文件数量一直处于上限时,说明 ingest 文件任务存在堆积,并且作业队列已达到最大长度。此时,可以采取以下措施来缓解任务堆积问题:- 设置
--ratelimit
参数来限制下载速度,以确保 ingest 文件任务有足够的资源。例如,当任意 TiKV 节点的硬盘吞吐量为x MiB/s
且下载备份文件的网络带宽大于x/2 MiB/s
,可以设置参数--ratelimit x/2
。如果任意 TiKV 节点的硬盘吞吐量为x MiB/s
且下载备份文件的网络带宽小于或等于x/2 MiB/s
,可以不设置参数--ratelimit
。 - 调高
--tikv-max-restore-concurrency
来增加作业队列的最大长度。
-
参考手册:
https://docs.pingcap.com/zh/tidb/stable/br-snapshot-guide