br 执行全量恢复，报错 Coprocessor task terminated due to exceeding the deadline

🪐 TiDB 技术问题 备份&数据迁移
1

【 TiDB 使用环境】生产环境 /测试/
【 TiDB 版本】TiDB v5.3.0、BR v5.3.0
【复现路径】
将生产环境的全量备份集做恢复测试时，报错 Coprocessor task terminated due to exceeding the deadline。

【遇到的问题：问题现象及影响】

Full restore <----------------------------------------------------------------------------------------------------------------------------------..............................................> 73.56%
Full restore <-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
[2023/07/24 11:05:53.139 +08:00] [INFO] [collector.go:65] ["Full restore failed summary"] [total-ranges=46104] [ranges-succeed=46104] [ranges-failed=0] [restore-checksum=5h11m42.859911719s] [split-region=1m47.011917972s] [restore-ranges=30688]
Error: other error: Coprocessor task terminated due to exceeding the deadline

["Full restore failed summary"] [total-ranges=46104] [ranges-succeed=46104] [ranges-failed=0] [restore-checksum=5h11m42.859911719s] [split-region=1m47.011917972s] [restore-ranges=30688]
[2023/07/24 11:05:53.139 +08:00] [ERROR] [restore.go:34] ["failed to restore"] [error="other error: Coprocessor task terminated due to exceeding the deadline"]

【资源配置】
1、生产环境（物理机部署）
3TiDB（64C/256G）、3TiKV（64C/256G）、3PD（64C/64G）
2、测试环境（PVE 虚拟化部署）
3TiDB（4C/8G）、3TiKV（4C/8G）、3PD（4C/4G）
3、数据量
快照大小 265G。
4、执行的恢复指令

export PD_ADDR="10.0.32.145:2379"
export BAKDIR="/tidb-bak/20230716"

nohup tiup br restore full --pd "${PD_ADDR}" --storage "local://${BAKDIR}" --ratelimit 64 --log-file restorefull_`date +%Y%m%d`.log &

【附件：截图/日志/监控】
dashboard 中关于 TiKV 的报错日至如下：

image
image1671×448 47.9 KB

2

测试集群和生产集群的版本一致吗， 测试集群在恢复之前存在相同名称的库表吗

3

应该是测试环境资源太低了吧，这个报错一般是tikv压力过大导致的

4

全新部署的与生产一致的软件版本及各节点角色的数量。
唯一的几点区别：测试环境硬件资源差一些，操作系统为openEuler 22.03（已通过tiup的OS检查）。生产环境的OS为Centos 7.9。

5

我初步也判断是测试环境资源不足的问题。重新执行了一次恢复，加入了 --ratelimit 64 参数，限制速率。不知是否有效。

6

是否有配置预定的时间限制

7

没有任何限制。全新的环境，官方的基础配置模板部署的测试环境。

8

加了 --ratelimit 64 仍然报同样的错。我再多分配些资源试下。

9

有个同样报错的案例

10

加了-L debug，提示找不到sst文件。初步判断是备份集文件拷贝过程中的损坏问题。但备份集是打了压缩包的，解压过程未报错。过些天，试试直接挂载nfs看看是否还报错。

11

md5校验了测试环境与生产环境备份集中的每个sst文件，文件未损坏。检查生产环境的备份日志，备份结束时有 2 个报错 [pd] fetch pending tso requests error]。但，最后提示 Full backup success summary。用这些备份集做 br 恢复，都是在恢复至 75% 左右，立即提示找不到sst 文件

12

在执行 BR 恢复命令时，如果出现 Coprocessor task terminated due to exceeding the deadline 的错误，这通常是由于 BR 工具的默认超时时间过短导致的。您可以尝试增加 --timeout 参数来延长 BR 工具的超时时间，例如：

tiup br restore full --pd “${PD_ADDR}” --storage “local://${BAKDIR}” --ratelimit 64 --log-file restorefull_date +%Y%m%d.log --timeout 7200s

以上命令将 BR 工具的超时时间设置为 7200 秒（2 小时），您可以根据实际情况进行调整

13

可以尝试以下方法进行排查：

  1. 检查备份集中的 SST 文件是否完整

虽然您已经对备份集中的每个 SST 文件进行了 MD5 校验，但是仍然有可能存在文件损坏的情况。您可以尝试重新检查备份集中的 SST 文件，确保它们都是完整的。如果发现有损坏的文件，可以尝试重新备份。

  1. 检查 BR 工具的版本是否正确

BR 工具的版本与 TiDB 集群的版本有关系，如果版本不匹配可能会导致 BR 工具无法正确识别备份集中的 SST 文件。您可以检查 BR 工具的版本是否与 TiDB 集群的版本匹配。如果版本不匹配，可以尝试升级 BR 工具或者降低 TiDB 集群的版本。

  1. 检查 BR 工具的参数是否正确

在执行 BR 恢复命令时，您需要指定一些参数，例如 PD 的地址、备份文件的存储路径等。如果这些参数设置不正确，可能会导致 BR 工具无法正确识别备份集中的 SST 文件。您可以检查 BR 恢复命令中的参数是否正确设置。

  1. 检查 TiKV 节点的磁盘空间是否充足

在进行 BR 恢复时，TiKV 节点需要将备份集中的 SST 文件写入磁盘。如果 TiKV 节点的磁盘空间不足，可能会导致 BR 恢复失败。您可以检查 TiKV 节点的磁盘空间是否充足。

14

limit限制到50了，timeout没试过。

15

这4个步骤都检查过了。