br备份卡住

🪐 TiDB 技术问题
1

【TiDB 使用环境】生产环境 /测试/ Poc
【TiDB 版本】
【操作系统】
【部署方式】云上部署（什么云）/机器部署（什么机器配置、什么硬盘）
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
今天检查日志又遇到 br 备份卡住的问题，参考之前br 备份一直卡住 - #18，来自 Denis 这个帖子的回复， 在执行 curl http://localhost:21365/debug/pprof/goroutine?debug=2 > goroutine_dump.txt 这个命令的时候大概2分钟还没有返回，想问一下这个命令大概要多久执行完？

2

在 TiDB 中，执行 curl http://localhost:21365/debug/pprof/goroutine?debug=2 > goroutine_dump.txt 命令的目的是抓取 BR（Backup & Restore）进程的 goroutine 堆栈信息，用于排查备份卡住等问题。该命令的执行时间受以下因素影响：

  1. BR 进程的 goroutine 数量
    如果 BR 进程中存在大量活跃的 goroutine（例如 thousands 级别），或部分 goroutine 处于阻塞 / 等待状态，堆栈信息的生成和输出会耗时更长，可能需要数十秒到几分钟。

  2. 系统负载与资源
    若 BR 所在节点的 CPU、内存资源紧张（例如备份本身已占用大量资源），进程响应会变慢，导致命令执行延迟。

  3. 网络与本地 I/O
    本地执行时网络影响可忽略，但如果节点磁盘 I/O 繁忙（例如备份正进行大量读写），输出文件（goroutine_dump.txt）的写入可能被阻塞，间接延长命令执行时间。

一般经验

  • 正常情况：若 BR 进程状态较简单（goroutine 数量较少，无严重阻塞），命令通常在 10-30 秒内完成。
  • 异常情况：当 BR 卡住且存在大量阻塞的 goroutine 时，命令可能需要 1-5 分钟，甚至更久（取决于阻塞程度）。

你遇到的 “2 分钟未返回” 可能属于 BR 进程本身状态异常（如大量 goroutine 阻塞）导致的正常现象，可耐心等待其完成。若超过 5 分钟仍无响应，可尝试：

  1. 检查 BR 进程是否还在运行（ps -ef | grep br）。
  2. 确认节点资源是否耗尽（top、free -m 查看 CPU / 内存）。
  3. 若进程无响应，可重启 BR 后重新尝试抓取（但会丢失当前卡住的堆栈信息，仅作为最后手段）。

抓取的 goroutine_dump.txt 中会包含所有 goroutine 的状态（如阻塞原因、等待的锁或资源），是排查 BR 卡住的关键依据。

3

昨天最久等了3小时也无返回，重启 br ，想要的 goroutine 也就不存在了吧

4

看你以前的帖子，用的是nfs备份？备份限速了嘛？带宽占满了可能导致nfs访问不了。最好还是用s3.

5

没有限速

6

1、重启会清除所有运行时的调试数据。
2、卡住的时候看下 goroutine_dump.txt里的内容，进行到哪里了，然后在看看当前系统负载那里比较高，CPU？IO?

7

goroutine_dump.txt 一直没有数据，br 备份卡住和生成 goroutine 的时候系统基本没什么负载

8

换高版本的试试