br备份失败报错

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

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
4.0版本

【概述】 场景 + 问题概述
br全备份，备份失败
日志报错：
[error=“rpc error: code = Canceled desc = context canceled”] [errorVerbose=“rpc error: code = Canceled desc = context canceled\ngithub.com/tikv/pd/client.(*client).GetAllStores\ \tgithub.com/tikv/pd@v1.1.0-beta.0.20201209075645-beb7635d13d2/client/client.go:653\ github.com/pingcap/br/pkg/conn.GetAllTiKVStores\ \tgithub.com/pingcap/br@/pkg/conn/conn.go:76\ github.com/pingcap/br/pkg/backup.(*Client).BackupRange\ \tgithub.com/pingcap/br@/pkg/backup/client.go:511\ github.com/pingcap/br/pkg/backup.(*Client).BackupRanges.func2.1\ \tgithub.com/pingcap/br@/pkg/backup/client.go:459\ github.com/pingcap/br/pkg/utils.(*WorkerPool).ApplyOnErrorGroup.func1\ \tgithub.com/pingcap/br@/pkg/utils/worker.go:63\ golang.org/x/sync/errgroup.(*Group).Go.func1\ \tgolang.org/x/sync@v0.0.0-20201020160332-67f06af15bc9/errgroup/errgroup.go:57\ runtime.goexit\ \truntime/asm_amd64.s:1357”] [unitName=“range start:7480000000000204de5f69800000000000000300 end:7480000000000204de5f698000000000000003fb”]

【备份和数据迁移策略逻辑】

【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 当前遇到的问题

【业务影响】

【TiDB 版本】

【附件】

  • 相关日志、配置文件、Grafana 监控（https://metricstool.pingcap.com/)
  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息
  • TiDB-Overview 监控
  • 对应模块的 Grafana 监控（如有 BR、TiDB-binlog、TiCDC 等）
  • 对应模块日志（包含问题前后 1 小时日志）

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

2

参考下这个看能解决吗，看报错一样的https://asktug.com/t/topic/68773

3

RPC调用报错？

1 个赞
4

不能。这个脚本之前备份是正常的，突然就不正常了。

5

日志报错是这样的，还有failed to connnect store这种报错。没别的了。

6

观察下各个节点的负载，看看有没有瓶颈
在执行 br 命令的时候，也可以观察下对各个节点的影响…

7

这个会有影响吗，我感觉不是这个的问题。我做了这样的测试。比如20220101那天备份脚本还能备份成功，20220102备份开始失败，我拿了20220101的全备到测试环境去恢复，又用mydumper备份数据库里面的部分表的新增数据，然后导入测试环境，在测试环境执行同样的脚本，是没有问题的。

8

或者有更多的场景描述？ 这样才能帮你做判断

9

这个节点的网络和 PD 网络好像有问题，看看是否可以 ping 的通 PD 节点呢？

10

10.****** | SUCCESS => {
“ping”: “pong”
}
10.****** | SUCCESS => {
“ping”: “pong”
}
10.****** | SUCCESS => {
“ping”: “pong”
}
10.****** | SUCCESS => {
“ping”: “pong”
}
10.****** | SUCCESS => {
“ping”: “pong”
}

11

可以ping的通

12

没有更多的场景了，display的时候，清一色的正常状态。业务量比较平稳，一直都是凌晨备份，有一天，突然就备份就失败了。我发论坛的时候贴出来的日志就是查看备份日志，grep error出来的。有一台机器的messages有如下错误，执行备份脚本的时候，

image
image944×76 33.1 KB

15

我大概知道这个问题在哪里，我今天对比各个storeid，我发现有个的tikv不存在，但是TIKV_STORE_STATUS表里面还有这个机器相关的信息，请问，我是否可以直接在表里面删除此条记录，或者可否用pd ctl delete对应的store

1 个赞
16

参考这个吧

https://docs.pingcap.com/zh/tidb/stable/pd-control#store-delete--label--weight--remove-tombstone--limit--store_id---jqquery-string

为啥节点状态不对？ 这个操作… :rofl:

另外可以用这个试试，
https://docs.pingcap.com/zh/tidb/stable/tiup-component-cluster-scale-in#下线特殊处理

2 个赞
17

之前的dba扩容的好像就有问题。除了目前这个状态不一致的kv节点，其他的节点都有数据，就这个一点数据都没有，估计是清理了数据，但是没有scale in，机器重启了，这个kv服务启动不起来了。就不一致了。应该就是这个问题。

1 个赞
18

:upside_down_face: 5.2.2的环境，直接干掉其他机器的kv（杀进程，rm -rf文件），scale-in ，prune，都没有问题（反正我测试的是没有问题）。4版本，在测试环境测，也没有问题。生产见鬼了。

1 个赞
19

报的是连接失败，是不是网络环境有变化

1 个赞
20

不是网络

21

您好，请问该问题解决了吗~

22

解决了。
这个问题的根源是这样的：
1.有个tikv的机器理应被scale in，因为它所在的机器上没有任何数据，而且服务是down的状态，但是没有被scale in的情况下，这台服务器上tikv服务重启了，而且没有启动起来，tiup cluster display看不到该tikv相关的信息
2.TIKV_STORE_STATUS表里面还有down掉的tikv机器的信息

3.处理操作：
tiup cluster scale-out clustername scale-out.yaml （命令执行结果为失败状态，但是tiup cluster display能看到IP对应tikv信息）
tiup cluster scale-in clustername -N ip:port --force
tiup cluster prune clustername

2 个赞