- 截图时间和 clinic 采集时间是对不上的
- 如果 “假设” 当成同一个原因导致的问题看，IP-24 的 backup worker 是跑的最高的，就看这个
3.说会 backup failed，采集的时间里，能找到的第一条就是 tikv service 给 BR 发 response 发不过去。说明 2022 @ 13:13:22.781 就有 backup request 接不到消息了。
- 至于是什么动作导致的 BR 端断连，没有对应时间点的 BR 日志，无法判定。
- 说回
txnLockFast backoffer.maxSleep 80000ms is exceeded，入口在这 → https://github.com/pingcap/tidb/blob/5263a0abda61f102122735049fd0dfadc7b7f8b2/br/pkg/backup/client.go#L798
backup range 被重试超过时间阈值就报错，代码里默认这种重拾的原因就是 txnLockFast
，可以看看日志里是否有 fine-grained-range-start，后面会锁定到 range 的 startkey and endkey。
现在有几点无法解释：
- 为什么 tikv backup response 回传 BR 发送失败，没有更多日志解释了.
- 这个 backoff 重试的到底是哪个表的 range，也不一定真的是因为解锁失败，只是代码里默认 backup request 下去会没有回传就是 txnlockfast. 得看下 br 在
txnLockFast backoffer.maxSleep 80000ms is exceeded之前的动作日志。