Dumpling下载失败

【 TiDB 使用环境`】生产
【 TiDB 版本】3.0.3
【遇到的问题】
下载命令:nohup /home/tidb/tidb-toolkit-v5.0.1-linux-amd64/bin/dumpling -u root -p’tidb’ -P 4000 -h 192.168.80.203 --filetype sql -t 16 -r 200000 -o /data > dumpling.out 2>&1 &
19:30开始下载, 23:39开始报错,

[mysql] 2022/10/09 23:39:24 packets.go:72: unexpected EOF
[mysql] 2022/10/09 23:39:24 packets.go:427: busy buffer
[2022/10/09 23:39:24.740 +08:00] [INFO] [collector.go:188] [“backup Failed summary : total backup ranges: 0, total success: 0, total failed: 0”]
[mysql] 2022/10/09 23:39:24 packets.go:72: unexpected EOF
[mysql] 2022/10/09 23:39:24 packets.go:427: busy buffer
[2022/10/09 23:39:24.744 +08:00] [ERROR] [main.go:77] [“dump failed error stack info”] [error=“sql: SELECT * FROM wtlivedbrds_xa.EVDataRT LIMIT 1: invalid connection”] [errorVerbose=“invalid connection\ sql: SELECT * FROM wtlivedbrds_xa.EVDataRT LIMIT 1\ngithub.com/pingcap/dumpling/v4/export.GetColumnTypes\ \tgithub.com/pingcap/dumpling@/v4/export/sql.go:307\ github.com/pingcap/dumpling/v4/export.dumpTableMeta\ \tgithub.com/pingcap/dumpling@/v4/export/dump.go:696\ github.com/pingcap/dumpling/v4/export.(*Dumper).dumpDatabases\ \tgithub.com/pingcap/dumpling@/v4/export/dump.go:302\ github.com/pingcap/dumpling/v4/export.(*Dumper).Dump\ \tgithub.com/pingcap/dumpling@/v4/export/dump.go:223\ main.main\ \tgithub.com/pingcap/dumpling@/cmd/dumpling/main.go:74\ runtime.main\ \truntime/proc.go:203\ runtime.goexit\ \truntime/asm_amd64.s:1357”]

dump failed: sql: SELECT * FROM wtlivedbrds_xa.EVDataRT LIMIT 1: invalid connection
最终连接失败,dump失败。
【复现路径】Dumpling下载测试了4次均失败,尝试将线程数-t由128改为64 、32,将-r改为100000还是报同样的错误失败。

手动连接 tidb 执行这个 SQL 试试。

手动执行这个sql没有问题。可以正常出结果

  1. 看下 tidb-server 的监控 uptime 时间,看看是否有重启
  2. 在 tidb server tidb.log 和 stderr log 中看看有没有 panic 内容

1.tidb-server在2022/10/09 23:39:40发生了重启。


2.tidb.log日志中无panic内容,可以看到23:39:40发生了重启。

stderr.log中在日志末尾有panic内容,但是看不到具体时间,具体报错说的是内存溢出。

好想不怎么行

4 个赞

和你每次 dumpling 失败时间能否对的上呢?
看起来就重启一次,看起来是 oom 了。

t 可以配置为 1 试试。

dumpling失败时间和重启时间可以对上。下班后我将-t改为8 试下。-r参数需要调整吗,需要全量下载的数据量很大

-r 可以不动,这个是单表并行导出用的。
不过你没有 panic 没有 oom 的话,不应该失败 :thinking:

将线程数调整后dumpling开始下载,在晚上22:10还是出现了下载失败的情况,tidb-server出现了重启,也有oom的情况出现,在22:10前查看slow日志也没有占用较高的sql


-t 再调小到 4 试试,-r 也可以调小到 5w
还不行试试 dumpling 6.x 比较新版本试试

今天下班再试下。

使用了6.1版本的dumpling,效果还是一样,断开连接,dumpling失败

将-r参数改为50000,-t参数改为16,从昨天8点开始下载,到晚上3点多连接中断。


按照这种方法试下呢,lighting碰到过这个问题,dumpling确实没有碰到,放到脚本里来执行试下

我就是在脚本里面执行的,不行。

https://github.com/pingcap/tidb/issues/31981

感觉和这个issue挺像的,dumpling造成的mom

而且看你的tidb版本是3,dumpling版本用到了5,可以试下4.0.15或者其他版本的dumpling试下

这个变量从4.0版本才开始引入,我的版本是3.0.3,还没有这个参数。%E5%9B%BE%E7%89%87
我下了个dumpling4.0.16版本,今天下班试下。

-t 不要搞这么大 先试试 1 行不行。