这个问题是好久以前的问题了,今天看自己的笔记,发现了这个问题,当时没有进行细看,想着现在复现一下。
 
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 statusG;可以看到:
当时解决的办法是,在备份脚本中添加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库找到了一样的问题: 
内容来源于网络如有侵权请私信删除

文章来源: 博客园

原文链接: https://www.cnblogs.com/ordinarydba/p/16284669.html

你还没有登录,请先登录注册
  • 还没有人评论,欢迎说说您的想法!