mydumper备份mysql8.0 sql thread被kill掉

这个问题是好久以前的问题了，今天看自己的笔记，发现了这个问题，当时没有进行细看，想着现在复现一下。

半夜收到测试数据库备份告警：

报警内容就是8002端口，备份失败，因为有慢查询导致的。

白天想着手动跑一下备份命令：

mydumper -u root  -S /tmp/mysql_8002.sock --kill-long-queries --regex '^(?!(test|information_schema|performance_schema|sys))' -o /data0/backup/sqldump/2021-06-11 --triggers --events  --routines -c

报错：

** (mydumper:40672): WARNING **: Killed a query that was running for 64s

此时又收到了主从状态的告警，登上从库show slave status\G;可以看到：

当时解决的办法是，在备份脚本中添加stop slave;然后再备份，备份完成后再start slave;该库也比较小，备份很快，不会产生太多延迟，再加上是凌晨备份，业务较少。

问题过去很久了，记不太清当时的场景了。现在猜测是有大事务，现在就来模拟一下大事务的场景，看看有没有这种现象发生：

数据库版本为8.0.21，mydumper版本为0.10.x

首先测试表有三条数据：

select * from t1;

+----+------+

| id | age  |

+----+------+

|  1 |  111 |

|  2 |  222 |

| 33 |    3 |

+----+------+

在主库开启事务执行update，并阻塞70s：

mysql> begin;

Query OK, 0 rows affected (0.00 sec)

mysql> update t1 set id=sleep(70)+3 where id=33;

Query OK, 1 row affected, 1 warning (20.01 sec)

Rows matched: 1  Changed: 1  Warnings: 1

mysql> commit;

此时在从库查看线程：

可以估计一下秒数，当超过60s的时候，执行备份命令：

mydumper -u root  -S /tmp/mysql_8002.sock --kill-long-queries --regex '^(?!(test|information_schema|performance_schema|sys))' -o /data0/backup/sqldump/2021-06-11 --triggers --events  --routines -c

此时报错：** (mydumper:37592): WARNING **: 16:43:23.791: Killed a query that was running for 63s

从库主从同步也报同样的错误。

复现成功，说明当时可能是有超过60s的大事务在执行。

mydumper中有两个重要的参数，说明一下：

① --long-query-guard ：

该参数可以修改备份被阻塞的时间，mydumper检查的时候是在执行的时候进行检查并不是一直在检查，当执行的时候检测到有超过该时间的慢查询，备份进程将立即结束；

② --kill-long-queries ：

该参数是杀掉慢查询，也是在执行开始的时候进行检查，默认是60s，当执行的时候检测到有超过60s的慢查询将其杀掉，然后继续进行备份；

以上两个参数可以联合起来使用，比如--long-query-guard 100就是当备份开始的时候，会检测有没有超过100s的慢查询，如果有的话会杀掉，然后继续进行备份（如果在备份开始的时候没有超过时间的慢查询，但是存在正在执行的慢查询，那么dump进程将会等待慢查询执行完成后，再进行备份）。

mydumper bug库：https://bugs.launchpad.net/mydumper/+bug/1713201