作者： lmdb 原文来源：https://tidb.net/blog/7f7663db
在 TiDB 中，BR（Backup & Restore）工具支持断点续传功能，主要用于在备份或恢复过程中因网络中断、节点故障等意外情况中断后，能够从断点处继续操作，避免重新执行整个流程，提高效率。
从 TiDB v7.1.0 起，备份恢复特性引入了断点恢复的功能
以下是关于 BR 断点续传的关键信息：
1. 断点续传的支持场景
BR 的断点续传主要针对 备份（br backup） 和 恢复（br restore） 操作，具体支持的场景包括：
测试案例，在 pingcap 库中保留 fund 表，然后对 pingcap 库做全库 br restore 操作，提示 “Full Restore failed summary”
MySQL [pingcap]> delete from fund where f_id = 3;Query OK, 1 row affected (0.02 sec)
MySQL [pingcap]> select * from fund;+-----------------+------+-----------+----------+------------+-----------+| f_name | f_id | f_type | f_amount | risk_level | f_manager |+-----------------+------+-----------+----------+------------+-----------+| 股票 | 1 | 股票型 | 10000 | 高 | 1 || 投资 | 2 | 债券型 | 10000 | 中 | 2 || 沪深300指数 | 4 | 指数型 | 10000 | 中 | 4 |+-----------------+------+-----------+----------+------------+-----------+3 rows in set (0.00 sec)
MySQL [pingcap]> exitBye[tidb@tidb01 pingcap]$ [tidb@tidb01 pingcap]$ [tidb@tidb01 pingcap]$ [tidb@tidb01 pingcap]$ [tidb@tidb01 pingcap]$ tiup br restore full \> --pd "192.168.2.73:2379" \> --filter 'pingcap.*' \> --ratelimit 128 \> -s "local:///tidb/backup/pingcap" \> --log-file /tidb/backup/pingcap/restore_pingcap_1023.log Starting component br: /home/tidb/.tiup/components/br/v8.5.2/br restore full --pd 192.168.2.73:2379 --filter pingcap.* --ratelimit 128 -s local:///tidb/backup/pingcap --log-file /tidb/backup/pingcap/restore_pingcap_1023.logDetail BR log in /tidb/backup/pingcap/restore_pingcap_1023.log Full Restore <-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%[2025/10/23 15:45:54.020 +08:00] [INFO] [collector.go:77] ["Full Restore failed summary"] [total-ranges=27] [ranges-succeed=27] [ranges-failed=0] [restore-ranges=14]Error: failed to validate checksum: [BR:Restore:ErrRestoreChecksumMismatch]restore checksum mismatch
复制代码
2. 断点续传的实现原理
在 br 恢复过程中因异常中断，会在数据库中产生一个新库，名字 “_TiDB_BR_Temporary_Snapshot_Restore_Checkpoint“
MySQL [(none)]> show databases;+-------------------------------------------------+| Database |+-------------------------------------------------+| INFORMATION_SCHEMA || METRICS_SCHEMA || PERFORMANCE_SCHEMA || __TiDB_BR_Temporary_Snapshot_Restore_Checkpoint || mysql || pingcap || sys || test |+-------------------------------------------------+8 rows in set (0.00 sec)
MySQL [(none)]> use "__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint"Database changedMySQL [__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint]> show tables;+-----------------------------------------------------------+| Tables_in___TiDB_BR_Temporary_Snapshot_Restore_Checkpoint |+-----------------------------------------------------------+| cpt_checksum || cpt_data || cpt_metadata |+-----------------------------------------------------------+3 rows in set (0.00 sec)
复制代码
在 TiDB BR（Backup & Restore）工具中，__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint 是一个临时内部表，主要用于在快照恢复（Snapshot Restore） 过程中记录恢复进度，支持断点续传功能。以下是关于该表的详细说明：
2.1 作用与功能
该表是 BR 在执行恢复操作时，自动在目标 TiDB 集群中创建的临时表，用于：
2.2 表的特性
临时性：仅在恢复过程中存在，恢复完成后会被 BR 自动删除（无论成功或失败，正常情况下都会清理）。
内部性：由 BR 工具自动创建和维护，用户无需手动操作，也不建议直接修改该表的数据，否则可能导致恢复异常。
存储位置：创建在目标 TiDB 集群的 mysql 系统数据库中，表名固定为 __TiDB_BR_Temporary_Snapshot_Restore_Checkpoint。
2.3 与断点续传的关联
BR 的快照恢复断点续传依赖该表的记录：
恢复开始时，BR 会创建该表并初始化进度信息。
恢复过程中，BR 会定期将已完成的任务进度（如已导入的 SST 文件、KV 范围）写入该表。
若恢复中断，重新执行恢复命令时，BR 会先检查该表是否存在：
若存在，读取进度信息，跳过已完成部分，继续处理剩余数据。
若不存在（如首次恢复、或上次恢复已清理），则从头开始恢复。
3. 使用方法
断点续传无需显式开启，只需在操作中断后，使用相同的命令参数重新执行备份或恢复命令即可。BR 会自动检测已完成的进度并从断点继续。
测试，我们 drop table fund 后继续执行上一次的 br restore 命令，提示 ”Full Restore success summary”，同时因异常产生的保存断点信息的库消失
MySQL [pingcap]> drop table fund;Query OK, 0 rows affected (0.40 sec)
MySQL [pingcap]> exitBye[tidb@tidb01 pingcap]$ [tidb@tidb01 pingcap]$ tiup br restore full --pd "192.168.2.73:2379" --filter 'pingcap.*' --ratelimit 128 -s "local:///tidb/backup/pingcap" --log-file /tidb/backup/pingcap/restore_pingcap_1023.log Starting component br: /home/tidb/.tiup/components/br/v8.5.2/br restore full --pd 192.168.2.73:2379 --filter pingcap.* --ratelimit 128 -s local:///tidb/backup/pingcap --log-file /tidb/backup/pingcap/restore_pingcap_1023.logDetail BR log in /tidb/backup/pingcap/restore_pingcap_1023.log Full Restore <-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%[2025/10/23 15:53:09.706 +08:00] [INFO] [collector.go:77] ["Full Restore success summary"] [total-ranges=27] [ranges-succeed=27] [ranges-failed=0] [restore-ranges=14] [total-take=6.474246733s] [BackupTS=461688651129028609] [RestoreTS=461689582670839832] [total-kv=491] [skipped-kv-count-by-checkpoint=487] [total-kv-size=7.363MB] [average-speed=1.137MB/s] [skipped-kv-size-by-checkpoint=7.363MB] [restore-data-size(after-compressed)=1.61MB] [Size=1609744][tidb@tidb01 pingcap]$ Your MySQL connection id is 1189104598Server version: 8.0.11-TiDB-v8.5.2 TiDB Server (Apache License 2.0) Enterprise Edition, MySQL 8.0 compatible
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MySQL [(none)]> show databases;+--------------------+| Database |+--------------------+| INFORMATION_SCHEMA || METRICS_SCHEMA || PERFORMANCE_SCHEMA || mysql || pingcap || sys || test |+--------------------+7 rows in set (0.00 sec)
MySQL [(none)]>
复制代码
通过断点续传，BR 工具能有效应对备份 / 恢复过程中的意外中断，减少重复操作的时间成本，尤其适合大规模数据场景。
评论