重要

你正在查看 TiDB 数据库的归档文档，归档文档不再提供任何更新。如无特殊需求，建议使用 TiDB 数据库的最新 LTS 版本。

Backup & Restore 常见问题

本文列出了在使用 Backup & Restore (BR) 时，可能会遇到的问题及相应的解决方法。

如果遇到未包含在此文档且无法解决的问题，可以在 AskTUG 社区中提问。

在 TiDB v5.4.0 及后续版本中，当在有负载的集群进行备份时，备份速度为什么会变得很慢？

从 TiDB v5.4.0 起，TiKV 的备份新增了自动调节功能。对于 v5.4.0 及以上版本，该功能会默认开启。当集群负载较高时，该功能会自动限制备份任务使用的资源，从而减少备份对在线集群的性能造成的影响。如需了解关于自动调节功能的更多信息，请参见自动调节。

TiKV 支持动态配置自动调节功能。因此，在开启或关闭该功能时，你不需要重启集群。以下为该功能的具体使用方法：

关闭功能：把 TiKV 配置项 backup.enable-auto-tune 设置为 false。
开启功能：把 backup.enable-auto-tune 设置为 true。对于 v5.3.x 版本的集群，当 TiDB 升级到 v5.4.0 及以上版本后，自动调节功能会默认关闭。这时，你可以通过该方式手动开启此功能。

如需了解通过 tikv-ctl 在线修改自动调节功能的命令行，请参阅自动调节功能的使用方法。

另外，自动调节功能减少了进行备份任务时默认使用的工作线程数量（详见 backup.num-threads）。因此，你通过 Grafana 监控面板看到的备份速度、CPU 使用率、I/O 资源利用率都会小于 v5.4 之前的版本。在 v5.4.0 之前的版本中，backup.num-threads 的默认值为 CPU 0.75，即处理备份任务的工作线程数量占了 75% 的逻辑 CPU，最大值为 32；在 v5.4.0 及之后的版本中，该配置项的默认值为 CPU 0.5，最大值为 8。

在离线备份场景中，你也可以使用 tikv-ctl 把 backup.num-threads 修改为更大的数字，从而提升备份任务的速度。

恢复的时候，报错 `could not read local://...:download sst failed`，该如何处理？

在恢复的时候，每个节点都必须能够访问到所有的备份文件 (SST files)。默认情况下，假如使用 local storage，备份文件会分散在各个节点中，此时是无法直接恢复的，必须将每个 TiKV 节点的备份文件拷贝到其它所有 TiKV 节点才能恢复。

建议在备份的时候挂载一块 NFS 网盘作为备份盘，详见将单表数据备份到网络盘。

BR 备份时，对集群影响多大？

对于 TiDB v5.4.0 及以后的版本，BR 不仅调低了备份任务的默认 CPU 使用率，还引入了 BR 自动调节功能。开启该功能后，当在集群高负载的场景下进行备份时，BR 能够自动限制备份任务使用的资源，从而限制 BR 备份的速度。因此，在 v5.4.0 高负载集群中使用默认配置进行备份时，备份任务对其集群性能的影响会显著小于 v5.4.0 之前的版本。

以下为单节点进行的内部测试。通过测试结果，可以确定，在全速备份场景下，使用 v5.4.0 版本及其前期版本的默认配置时，BR 备份对集群性能的影响有较大区别。具体测试结果如下：

使用 v5.3.0 的默认配置时，纯写负载的 QPS 降低了 75%；
使用 v5.4.0 的默认配置时，相同负载的 QPS 降低了 25%。不过，使用该配置时，BR 备份任务的耗时也相应增加，约为 v5.3.0 配置下的 1.7 倍。

你可以通过如下方案手动控制 BR 备份对集群性能带来的影响。但是，这两种方案在减少 BR 备份对集群的影响的同时，也会降低备份任务的速度。

使用 --ratelimit 参数对备份任务进行限速。请注意，这个参数限制的是把备份文件存储到外部存储的速度。计算备份文件的大小时，请以备份日志中的 backup data size(after compressed) 为准。
调节 TiKV 配置项 backup.num-threads，限制备份任务使用的工作线程数量。过往的测试数据表明，当 BR 备份的线程数量不大于 8、集群总 CPU 利用率不超过 60% 时，BR 备份任务对集群（无论读写负载）几乎没有影响。

BR 会备份系统表吗？在数据恢复的时候，这些系统表会冲突吗？

在 v5.1.0 之前，BR 备份时会过滤掉系统库 mysql.* 的表数据。自 v5.1.0 起，BR 默认备份集群内的全部数据，包括系统库 mysql.* 中的数据。但由于恢复 mysql.* 中系统表数据的技术实现尚不完善，因此 BR 默认不恢复系统库 mysql 中的表数据。详情参阅备份和恢复 mysql 系统库下的表数据（实验特性）。

BR 遇到 Permission denied 或者 No such file or directory 错误，即使用 root 运行 BR 也无法解决，该如何处理？

需要确认 TiKV 是否有访问备份目录的权限。如果是备份，确认是否有写权限；如果是恢复，确认是否有读权限。

在进行备份操作时，如果使用本地磁盘或 NFS 作为存储介质，请确保执行 BR 的用户和启动 TiKV 的用户相同（如果 BR 和 TiKV 位于不同的机器，则需要用户的 UID 相同），否则备份可能会出现该问题。。

使用 root 运行 BR 仍旧有可能会因为磁盘权限而失败，因为备份文件 (SST) 的保存是由 TiKV 执行的。

注意

在恢复的时候也可能遇到同样的问题。

使用 BR 进行数据的恢复时，检验读权限的时机是在第一次读取 SST 文件时，考虑到执行 DDL 的耗时，这个时刻可能会离开始运行 BR 的时间很远。这样可能会出现等了很长时间之后遇到 Permission denied 错误失败的情况。

因此，最好在恢复前提前检查权限。

你可以按照如下步骤进行权限检查：

执行 Linux 原生的进程查询命令

ps aux | grep tikv-server

命令输出示例如下:

tidb_ouo  9235 10.9  3.8 2019248 622776 ?      Ssl  08:28   1:12 bin/tikv-server --addr 0.0.0.0:20162 --advertise-addr 172.16.6.118:20162 --status-addr 0.0.0.0:20188 --advertise-status-addr 172.16.6.118:20188 --pd 172.16.6.118:2379 --data-dir /home/user1/tidb-data/tikv-20162 --config conf/tikv.toml --log-file /home/user1/tidb-deploy/tikv-20162/log/tikv.log
tidb_ouo  9236  9.8  3.8 2048940 631136 ?      Ssl  08:28   1:05 bin/tikv-server --addr 0.0.0.0:20161 --advertise-addr 172.16.6.118:20161 --status-addr 0.0.0.0:20189 --advertise-status-addr 172.16.6.118:20189 --pd 172.16.6.118:2379 --data-dir /home/user1/tidb-data/tikv-20161 --config conf/tikv.toml --log-file /home/user1/tidb-deploy/tikv-20161/log/tikv.log

或者执行以下命令：

ps aux | grep tikv-server | awk '{print $1}'

命令输出示例如下:

tidb_ouo
tidb_ouo

使用 TiUP 命令查询集群的启动信息

tiup cluster list

命令输出示例如下：

[root@Copy-of-VM-EE-CentOS76-v1 br]# tiup cluster list
Starting component `cluster`: /root/.tiup/components/cluster/v1.5.2/tiup-cluster list
Name          User      Version  Path                                               PrivateKey
----          ----      -------  ----                                               ----------
tidb_cluster  tidb_ouo  v5.0.2   /root/.tiup/storage/cluster/clusters/tidb_cluster  /root/.tiup/storage/cluster/clusters/tidb_cluster/ssh/id_rsa

检查备份目录的权限，例如 backup 目录是备份数据存储目录。命令示例如下：
```
ls -al backup
```
命令输出示例如下：
```
[root@Copy-of-VM-EE-CentOS76-v1 user1]# ls -al backup
total 0
drwxr-xr-x  2 root root   6 Jun 28 17:48 .
drwxr-xr-x 11 root root 310 Jul  4 10:35 ..
```
由以上命令输出结果可知，tikv-server 实例由用户 tidb_ouo 启动，但该账号没有 backup 目录的写入权限，所以备份失败。

BR 遇到错误信息 `Io(Os...)`，该如何处理？

这类问题几乎都是 TiKV 在写盘的时候遇到的系统调用错误。例如遇到 Io(Os { code: 13, kind: PermissionDenied...}) 或者 Io(Os { code: 2, kind: NotFound...})。

首先检查备份目录的挂载方式和文件系统，尝试备份到其它文件夹或者硬盘。

目前已知备份到 samba 搭建的网盘时可能会遇到 Code: 22(invalid argument) 错误。

BR 遇到错误信息 `rpc error: code = Unavailable desc =...`，该如何处理？

该问题一般是因为使用 BR 恢复数据的时候，恢复集群的性能不足导致的。可以从恢复集群的监控或者 TiKV 日志来辅助确认。

要解决这类问题，可以尝试扩大集群资源，以及调小恢复时的并发度 (concurrency)，打开限速 (ratelimit) 设置。

使用 local storage 的时候，BR 备份的文件会存在哪里？

在使用 local storage 的时候，会在运行 BR 的节点生成 backupmeta，在各个 Region 的 Leader 节点生成备份文件。

备份数据有多大，备份会有副本吗？

备份的时候仅仅在每个 Region 的 Leader 处生成该 Region 的备份文件。因此备份的大小等于数据大小，不会有多余的副本数据。所以最终的总大小大约是 TiKV 数据总量除以副本数。

但是假如想要从本地恢复数据，因为每个 TiKV 都必须要能访问到所有备份文件，在最终恢复的时候会有等同于恢复时 TiKV 节点数量的副本。

BR 恢复到 TiCDC / Drainer 的上游集群时，要注意些什么？

BR 恢复的数据无法被同步到下游，因为 BR 直接导入 SST 文件，而下游集群目前没有办法获得上游的 SST 文件。
在 4.0.3 版本之前，BR 恢复时产生的 DDL jobs 还可能会让 TiCDC / Drainer 执行异常的 DDL。所以，如果一定要在 TiCDC / Drainer 的上游集群执行恢复，请将 BR 恢复的所有表加入 TiCDC / Drainer 的阻止名单。

TiCDC 可以通过配置项中的 filter.rules 项完成，Drainer 则可以通过 syncer.ignore-table 完成。

BR 会备份表的 `SHARD_ROW_ID_BITS` 和 `PRE_SPLIT_REGIONS` 信息吗？恢复出来的表会有多个 Region 吗？

会的，BR 会备份表的 SHARD_ROW_ID_BITS 和 PRE_SPLIT_REGIONS 信息，并恢复成多个 Region。

使用 BR 恢复备份数据时，BR 会报错 `entry too large, the max entry size is 6291456, the size of data is 7690800`

你可以尝试降低并发批量建表的大小，将 --ddl-batch-size 设置为 128 或者更小的值。

在 --ddl-batch-size 的值大于 1 的情况下，使用 BR 恢复数据时，TiDB 会把执行创建表任务的 DDL job 队列写到 TiKV 上。由于 TiDB 能够一次性发送的 job message 的最大值默认为 6 MB（不建议修改此值，具体内容，参考 txn-entry-size-limit 和 raft-entry-max-size），TiDB 单次发送的所有表的 schema 大小总和也不应该超过 6 MB。因此，如果你设置的 --ddl-batch-size 的值过大，TiDB 单次发送的批量表的 schema 大小就会超出规定值，从而导致 BR 报 entry too large, the max entry size is 6291456, the size of data is 7690800 错误。

使用 BR 恢复备份数据后，SQL 查询报错 `region is unavailable`

如果 BR 备份的集群有 TiFlash，恢复时会将 TiFlash 信息存进 TableInfo。此时如果恢复的集群没有 TiFlash，则会报该错误。计划在未来版本中修复该错误。

BR 是否支持就地 (in-place) 全量恢复某个历史备份？

不支持。

在 Kubernetes 环境中如何使用 BR 进行增量备份？

可以使用 kubectl 执行 kubectl -n ${namespace} get bk ${name} 以获得上次 BR 备份 commitTs 字段，该字段的内容可作为 --lastbackupts 使用。

BR backupTS 如何转化成 Unix 时间？

BR backupTS 默认是在备份开始前，从 PD 获取到的最新时间戳。可以使用 pd-ctl tso timestamp 来解析该时间戳，以获得精确值，也可以通过 backupTS >> 18 来快速获取估计值。

BR 恢复存档后是否需要对表执行 `ANALYZE` 以更新 TiDB 在表和索引上留下的统计信息？

BR 不会备份统计信息（v4.0.9 除外）。所以在恢复存档后需要手动执行 ANALYZE TABLE 或等待 TiDB 自动进行 ANALYZE。

BR v4.0.9 备份统计信息使 BR 消耗过多内存，为保证备份过程正常，从 v4.0.10 开始默认关闭备份统计信息的功能。

如果不对表执行 ANALYZE，TiDB 会因统计信息不准确而选不中最优化的执行计划。如果查询性能不是重点关注项，可以忽略 ANALYZE。

是否可以同时使用多个 BR 进程对单个集群进行恢复？

强烈不建议在单个集群中同时使用多个 BR 进程进行恢复，原因如下：

BR 在恢复数据时，会修改 PD 的一些全局配置。如果同时使用多个 BR 进程进行恢复，这些配置可能会被错误地覆写，导致集群状态异常。
因为 BR 在恢复数据的时候会占用大量集群资源，事实上并行恢复能获得的速度提升也非常有限。
多个 BR 并行恢复的场景没有经过测试，无法保证成功。

备份日志中出现 `key locked Error`，该如何处理？

日志中的错误消息：log - ["backup occur kv error"][error="{\"KvError\":{\"locked\":

如果在备份过程中遇到 key 被锁住，目前 BR 会尝试清锁。少量报错不会影响备份的正确性。

备份失败该如何处理？

日志中的错误消息：log - Error: msg:"Io(Custom { kind: AlreadyExists, error: \"[5_5359_42_123_default.sst] is already exists in /dir/backup_local/\" })"

若备份失败并出现以上错误消息，采取以下其中一种操作后再重新备份：

更换备份数据目录。例如将 /dir/backup-2020-01-01/ 改为 /dir/backup_local/。
删除所有 TiKV 和 BR 节点的备份目录。

BR 备份恢复后监控显示磁盘使用空间不一致

这个情况多数是因为备份时集群的数据压缩比率和恢复时的默认值不一致导致的，只要恢复的 checksum 阶段顺利通过，可以忽略这个问题，不影响正常使用。

恢复 Placement Rule 到集群时为什么会报错？

BR 在 v6.0.0 之前不支持放置规则。BR v6.0.0 及以上版本开始支持并提供了命令行选项 --with-tidb-placement-mode=strict/ignore 来控制放置规则的导入模式。默认值为 strict，代表导入并检查放置规则，当--with-tidb-placement-mode 设置为 ignore 时，BR 会忽略所有的放置规则。

BR 为什么会报 `new_collations_enabled_on_first_bootstrap` 不匹配？

从 TiDB v6.0.0 版本开始，new_collations_enabled_on_first_bootstrap 配置项的默认值由 false 改为 true。BR 会备份上游集群的 new_collations_enabled_on_first_bootstrap 配置项。当上下游集群的此项配置相同时，BR 才会将上游集群的备份数据安全地恢复到下游集群中。若上下游的该配置不相同，BR 会拒绝恢复，并报此配置项不匹配的错误。

如果需要将旧版本的备份数据恢复到 TiDB v6.0.0 或更新版本的 TiDB 集群中，你需要检查上下游集群中的该配置项是否相同：

若该配置项相同，则可在恢复命令中添加 --check-requirements=false 以跳过此项配置检查。
若该配置项不相同，且进行强行恢复，BR 会报数据校验错误。

下载 PDF