使用 BR 恢复集群

使用 BR 恢复集群

本文介绍恢复 TiDB 集群的方式，包括：

恢复快照备份数据
恢复单个数据库的数据
恢复单张表的数据
使用表库功能过滤恢复数据
从远端存储恢复备份数据
恢复增量备份数据
恢复加密的备份数据
恢复创建在 mysql 数据库下的表

如果你还不熟悉恢复工具，建议先阅读以下文档，充分了解恢复工具的使用方法和限制：

如果你需要恢复 Dumpling 导出的数据、CSV 文件或 Amazon Aurora 生成的 Apache Parquet 文件，可以使用 TiDB Lightning 来导入数据，实现恢复。具体恢复操作，请参考使用 TiDB Lightning 恢复全量数据。

恢复快照备份数据

BR 支持在一个空集群上执行快照备份恢复，将该集群恢复到快照备份时刻点的集群最新状态。

用例：将 s3 的名为 backup-data bucket 下的 2022-01-30/ 前缀目录中属于 2022-01-30 07:42:23 时刻点的快照数据恢复到目标机群。

br restore full \
    --pd "${PDIP}:2379" \
    --storage "s3://backup-data/2022-01-30/" \
    --ratelimit 128 \
    --log-file restorefull.log

以上命令中，

--ratelimit：每个 TiKV 执行恢复任务的速度上限（单位 MiB/s）
--log-file：BR log 写入的目标文件

恢复期间还有进度条会在终端中显示，进度条效果如下。当进度条前进到 100% 时，说明恢复已完成。在完成恢复后，BR 为了确保数据安全性，还会校验恢复数据。

br restore full \
    --pd "${PDIP}:2379" \
    --storage "s3://backup-data/2022-01-30/" \
    --ratelimit 128 \
    --log-file restorefull.log
Full Restore <---------/...............................................> 17.12%.

恢复备份数据中指定库表的数据

BR 支持只恢复备份数据中指定库/表的局部数据。该功能在恢复过程中过滤掉不需要的数据，可以用于往 TiDB 集群上恢复指定库/表的数据。

恢复单个数据库的数据

要将备份数据中的某个数据库恢复到集群中，可以使用 br restore db 命令。执行 br restore db --help 可获取该命令的使用帮助。

用例：将 s3 中名为 backup-data 的 bucket 下的 db-test/2022-01-30/ 中的 test 库的相关数据恢复到集群中。

br restore db \
    --pd "${PDIP}:2379" \
    --db "test" \
    --ratelimit 128 \
    --storage "s3://backup-data/db-test/2022-01-30/" \
    --log-file restore_db.log

以上命令中 --db 选项指定了需要恢复的数据库名字。其余选项的含义与恢复快照备份数据相同。

注意：

恢复备份数据的时候，--db 选项指定的数据库名必须与执行备份时候 --db选项指定的数据库名相同，否则无法恢复成功。由于备份数据的元文件backupmeta 记录了该数据库名，因此只能将数据恢复到同名的数据库。推荐做法是把备份文件恢复到另一个集群的同名数据库中。

恢复单张表的数据

要将备份数据中的某张数据表恢复到集群中，可以使用 br restore table 命令。该命令的使用帮助可通过 br restore table --help 来获取。

用例：将 s3 中名为 backup-data 的 bucket 下的 table-db-usertable/2022-01-30/ 中的 test.usertable 表的相关的数据恢复的集群中。

br restore table \
    --pd "${PDIP}:2379" \
    --db "test" \
    --table "usertable" \
    --ratelimit 128 \
    --storage "s3://backup-data/table-db-usertable/2022-01-30/" \
    --log-file restore_table.log

以上命令中 --table 选项指定了需要恢复的表名。其余选项的含义与恢复单个数据库相同。

使用表库功能过滤恢复数据

如果你需要用复杂的过滤条件来恢复多个表，执行 br restore full 命令，并用 --filter 或 -f 指定使用表库过滤。

用例：将 s3 中名为 backup-data 的 bucket 下的 table-filter/2022-01-30/ 中能匹配上 db*.tbl*的表的相关的数据恢复的集群中。

br restore full \
    --pd "${PDIP}:2379" \
    --filter 'db*.tbl*' \
    --storage "s3://backup-data/table-filter/2022-01-30/"  \
    --log-file restorefull.log

从远端存储恢复备份数据

BR 支持将数据备份到 Amazon S3、Google Cloud Storage、Azure Blob Storage、NFS 或者实现 S3 协议的其他文件存储服务。关于如何从对应的备份存储中恢复备份数据，请参考如下文档：

恢复增量备份数据

警告：

当前该功能为实验特性，不建议在生产环境中使用。

增量恢复的方法和使用 BR 进行快照恢复的方法并无差别。需要注意，恢复增量数据的时候，需要保证备份时指定的 last backup ts 之前备份的数据已经全部恢复到目标集群。同时因为增量恢复的时候会更新 ts 数据，因此你需要保证此时不会有其他写入，避免出现冲突。

br restore full \
    --pd "${PDIP}:2379" \
    --storage "s3://backup-data/2022-01-30/incr"  \
    --ratelimit 128 \
    --log-file restorefull.log

恢复加密的备份数据

警告：

当前该功能为实验特性，不建议在生产环境中使用。

在对数据做加密备份后，恢复操作需传入相应的解密参数，解密算法或密钥不正确则无法恢复，解密参数和加密参数一致即可。解密恢复的示例如下：

br restore full\
    --pd ${PDIP}:2379 \
    --storage "s3://backup-data/2022-01-30/" \
    --crypter.method aes128-ctr \
    --crypter.key 0123456789abcdef0123456789abcdef

恢复创建在 `mysql` 数据库下的表

警告：

当前该功能为实验特性，不建议在生产环境中使用。

BR 会默认备份 mysql 数据库下的表。在执行恢复时，mysql 下的表默认不会被恢复。如果需要恢复 mysql 下的用户创建的表，可以通过 table filter 来显式地包含目标表。以下示例中要恢复目标用户表为 mysql.usertable；该命令会在执行正常的恢复的同时恢复 mysql.usertable。

br restore full -f '*.*' -f '!mysql.*' -f 'mysql.usertable' -s $external_storage_url --ratelimit 128

在上面的命令中，

-f '*.*' 用于覆盖掉默认的规则。
-f '!mysql.*' 指示 BR 不要恢复 mysql 中的表，除非另有指定。
-f 'mysql.usertable' 则指定需要恢复 mysql.usertable。

如果只需要恢复 mysql.usertable，而无需恢复其他表，可以使用以下命令：

br restore full -f 'mysql.usertable' -s $external_storage_url --ratelimit 128

警告：

系统表（例如 mysql.tidb）可以通过 BR 进行备份。但恢复系统表存在限制。即便是使用了 -filter 设置，也不能通过 BR 恢复以下系统表

统计信息表（mysql.stat_*）
系统变量表（mysql.tidb、mysql.global_variables）
用户信息表（mysql.user、mysql.columns_priv、tables_priv，等等）
其他系统表

恢复系统表可能还存在更多兼容性问题。为了防止意外发生，请避免在生产环境中恢复系统表。