mydumper备份mysql8.0 sql thread被kill掉，1、半夜收到测试数据

mydumper备份mysql8.0 sql thread被kill掉，1、半夜收到测试数据

这个问题是好久以前的问题了，今天看自己的笔记，发现了这个问题，当时没有进行细看，想着现在复现一下。   1、半夜收到测试数据库备份告警： 报警内容就是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;该库也比较小，备份很快，不会产生太多延迟，再加上是凌晨备份，业务较少。   问题过去很久了，记不太清当时的场景了，悔恨当时没有详细的记录啊。   2、现在猜测是有大事务，现在就来模拟一下大事务的场景，看看有没有这种现象发生： 数据库版本为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;   3、此时在从库查看线程： 可以估计一下秒数，当超过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的大事务在执行。   4、mydumper中有两个重要的参数，说明一下： ① --long-query-guard ： 该参数可以修改备份被阻塞的时间，mydumper检查的时候是在执行的时候进行检查并不是一直在检查，当执行的时候检测到有超过该时间的慢查询，备份进程将立即结束； ② --kill-long-queries ： 该参数是杀掉慢查询，也是在执行开始的时候进行检查，默认是60s，当执行的时候检测到有超过60s的慢查询将其杀掉，然后继续进行备份； 以上两个参数可以联合起来使用，比如--long-query-guard 100就是当备份开始的时候，会检测有没有超过100s的慢查询，如果有的话会杀掉，然后继续进行备份（如果在备份开始的时候没有超过时间的慢查询，但是存在正在执行的慢查询，那么dump进程将会等待慢查询执行完成后，再进行备份）。   5、在mydumper bug库找到了一样的问题：  mydumper bug库：https://bugs.launchpad.net/mydumper/+bug/1713201