[Mydumper] Lost connection to MySQL server during query

liubb · 2019 年8 月 28 日 10:15

Server version: 5.7.25-TiDB-v2.1.8
集群信息：
tidb:1台
pd: 1台
kv:3台

在使用mydumper备份是时候报错。Lost connection to MySQL server during query

./mydumper -h 127.0.0.1 -P 4000 -u username -p password -t 16 -F 64 -B dbname --skip-tz-utc -o /backups/dbane

qizheng · 2019 年8 月 28 日 13:52

可以尝试将 -t 调小一些，可能下游有 oom 导致连接断开。

liubb · 2019 年8 月 29 日 02:33

和指定的并发无关，我尝试修改，测试过设置为1.还是报错

** (mydumper:15320): CRITICAL **: 10:19:04.199: Could not read data from gateway.method_invoke_detail: Lost connection to MySQL server during query

** (mydumper:15320): CRITICAL **: 10:19:04.200: Error dumping schemas (gateway.method_invoke_detail): MySQL server has gone away

alex.liu012 · 2019 年8 月 31 日 07:18

上面没有谈到你的数据量，如果比较大的话，下面的建议应该对你有帮助。

连接断开的话，可能有下面两个原因

1 备份时长大于gc时长

连接断开的问题，建议你看一下tidb的gc时长，如果你没有设置，应该为默认的10m0s，

如果在备份的时候，如果备份的时间超过默认的gc时长：10分钟，就会出现断开的问题。

建议参考官方方法，设置比较大的gc时长，等备份结束之后，再设置回来。

2 tidb发生oom

如果备份的数据量比较大，因为看到你的tidb版本是2.1.8，而tidb在2.1.13之前，使用mydumper备份数据的时候，都会将数据读到内存，容易引发tidb oom。

这种情况下，1）是建议你调大tidb的内存阈值。 2）是升级你的tidb版本。

希望上面的建议能对你有帮助

Victor · 2019 年9 月 1 日 03:19

数据量很大嘛？

Victor · 2019 年9 月 1 日 03:20

如果备份的时间超过默认的gc时长：10分钟，就会出现断开的问题。

不会导致断开，会导致备份失败

liubb · 2019 年9 月 2 日 03:40

有可能，但是现在的数据量也不是很大。最初是有备份成功过的

liubb · 2019 年9 月 2 日 05:15

尝试调整gc时常。文档上的

update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_life_time';

但是，还是出现同样的错误，Lost connection to MySQL server during query

tidb的内存阈值在那里调整？

liubb · 2019 年9 月 2 日 06:39

8百万行，3个kv节点，单节点上data目录 7G+ ，好像是oom了

alex.liu012 · 2019 年9 月 3 日 11:14

如果是oom了，比较简单的方式，调整容器的内存阈值，尽可能的大。

另外一种方法就是建议你升级你的tidb版本，升级到2.1.3之后。

具体的看tidb相关的issue：

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

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

alex.liu012 · 2019 年9 月 3 日 11:15

超时默认gc时长，是会出现上面的lost connetion to mysql 错误的

liubb · 2019 年10 月 28 日 02:36

版本升级到了最新过的 Server version: 5.7.25-TiDB-v3.0.5 但是备份还是有问题，尝试过调整备份的线程 -t 1 但是备份还是失败。

也修改过gc的时长

update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_life_time';

可是问题依旧 ** (mydumper:717): CRITICAL **: 10:30:58.382: Could not read data from gateway.method_invoke_detail: Lost connection to MySQL server during query

shenli-PingCAP · 2019 年10 月 28 日 02:39

升级后是否还是出现了 OOM？

OG.Ana-PingCAP · 2019 年10 月 28 日 02:42

看一下你这边 tidb-server 进程有没有 oom 重启过吧。另外确认下如果是数据量很小的情况，会出现这样的情况吗？

liubb · 2019 年10 月 28 日 03:05

看日志是有出现oom。但是数据量不算大啊

| data_length_MB | index_length_MB |
+----------------+-----------------+
| 60977.28MB     | 990.58MB        |
+----------------+-----------------+```

OG.Ana-PingCAP · 2019 年10 月 28 日 03:14

tidb-server 的机器内存有多大呀。

liubb · 2019 年10 月 28 日 03:16

              total        used        free      shared  buff/cache   available
Mem:           7821         552        6742           0         526        7016
Swap:             0           0           0

Gin · 2019 年10 月 28 日 03:16

TiDB 改版的 mydumper 具备单表多并发备份功能，适用于某张表特别大，占用很多内存的场景：

下载 tidb 社区最新版本的 mydumper https://www.pingcap.com/docs-cn/v3.0/reference/tools/download/
添加 -r 参数，规定每个并发处理的数据量-r, --rows Try to split tables into chunks of this many rows. This option turns off --chunk-filesize

OG.Ana-PingCAP · 2019 年10 月 28 日 03:17

你是在当前机器查这台机器的 tidb-server 这样的话，tidb-server 要占内存，你读过来还要用 8G 肯定不够了呀。

OG.Ana-PingCAP · 2019 年10 月 28 日 03:18

换一台机器试试，或者试一下最新版。