【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
版本为7.1.5，备份日志一直在刷
[2024/09/20 19:06:05.457 +08:00] [INFO] [checkpoint.go:610] [“start to flush the checkpoint lock”] [lock-at=1726830365012] [expire-at=1726830665012]
[2024/09/20 19:10:05.264 +08:00] [INFO] [checkpoint.go:610] [“start to flush the checkpoint lock”] [lock-at=1726830605062] [expire-at=1726830905062]
[2024/09/20 19:14:04.749 +08:00] [INFO] [checkpoint.go:610] [“start to flush the checkpoint lock”] [lock-at=1726830844662] [expire-at=1726831144662]
[2024/09/20 19:18:05.438 +08:00] [INFO] [checkpoint.go:610] [“start to flush the checkpoint lock”] [lock-at=1726831085062] [expire-at=1726831385062]
[2024/09/20 19:22:06.056 +08:00] [INFO] [checkpoint.go:610] [“start to flush the checkpoint lock”] [lock-at=1726831325762] [expire-at=1726831625762]
[2024/09/20 19:26:05.081 +08:00] [INFO] [checkpoint.go:610] [“start to flush the checkpoint lock”] [lock-at=1726831564812] [expire-at=1726831864812]
[2024/09/20 19:30:05.177 +08:00] [INFO] [checkpoint.go:610] [“start to flush the checkpoint lock”] [lock-at=1726831805062] [expire-at=1726832105062]
[2024/09/20 19:34:05.030 +08:00] [INFO] [checkpoint.go:610] [“start to flush the checkpoint lock”] [lock-at=1726832044911] [expire-at=1726832344911]
[2024/09/20 19:38:05.573 +08:00] [INFO] [checkpoint.go:610] [“start to flush the checkpoint lock”] [lock-at=1726832285162] [expire-at=1726832585162]
没有往后的进展，这个场景应该如何定位问题？
这看上去没啥问题，info级别的日志，就是输出一下lock的两个时间戳，然后转成json写入文件。
有问题的部分在于json的序列化失败或者写入文件失败。
如果日志中没有这部分报错，仅目前的info信息，br备份并没有问题。
你感觉一直卡着，可能是每个region上的lock信息都要重新写入更新一遍。这是断点机制要求的。
https://docs.pingcap.com/zh/tidb/stable/br-checkpoint-backup
在快照备份过程中，br 工具将表编码成对应的键空间，并生成备份的 RPC 请求发送给所有 TiKV 节点。接收到备份请求后，TiKV 节点会选择请求范围内的数据进行备份。每当 TiKV 节点备份完一个 Region 级别的数据，就会返回给 br 工具这段范围相关的备份信息。
现在是日志一直只有这些显示，最后退出备份，没有备份成功的summary相关信息。感觉备份没有成功
看看会话有没有锁
重新启动一次备份，还是卡在 flush the checkpoint lock 位置，查看3个 tidb 节点，没有锁
有其他的日志信息吗？起码这个start to flush the checkpoint lock不像是备份没有完成的原因。
检查是否有长事务或者锁争用导致锁无法及时释放。可以通过 information_schema.data_lock_waits 表来查看当前的锁等待情况，以及通过 information_schema.cluster_tidb_trx 来查看事务的详细情况。
没有锁等待的情况的，事务都是 IDLE 状态
时间是有点长，看样子还在运行，日志上也确实看不出有什么其他问题。
进入这个断点备份的逻辑，说明有一次备份的中途因为什么原因断掉过一次。
如果实在不行，建议把原来的备份彻底删掉，重新备份，不触发断点备份，看看能否成功。
重新备份下试试？
重新备份 还是失败，已经重新备份三次了
SHOW BACKUPS; 可以看到进度不
没有进度，empty set
br 备份进度条一点都没推进么？
上面日志有完整的么？
重跑也是每次备份很久后无故退出？
[“start to flush the checkpoint lock”] 是定期刷新进度，应该不会影响备份。
上传一下backup的监控图看看？
是备份很久后无故退出，backup的监控图从哪获得
BR 卡住的时候可以通过如下步骤启动 pprof 并且抓到 goroutine dump，如果可以上传的话对诊断会很有帮助：
- 对 BR 进程发送
SIGUSR1:pkill -USR1 br或者kill -USR1 $(pgrep br) - BR 此时会打印一条日志 “bound pprof to addr”，这条日志里面会有 pprof 启动的端口，记为
$pprof_port。 - 通过
curl http://localhost:$pprof_port/debug/pprof/goroutine?debug=2 > goroutine_dump.txt获得 goroutine dump。
另：之前偶尔遇到过类似情况，当时原因是 BR 的 stderr 被不明原因阻塞了，导致 summary 一直打印不出来，所以卡死了。
我也遇到了，br备份了两次，也没有删除之前的记录，只是重新跑了一遍，侥幸好了。但不知道原因，也不明白怎么去定位产生原因