mydumper原理2

时间:2023-03-08 16:15:36

使用mydumper备份发生Waiting for table flush,导致所有线程都无法读和写

版本 mydumper 0.9.1
OS centos6.6 X86_64
mysql 5.6.25-log

mydumper备份选项 mydumper -h $HOST -u $USER -p $PASSWORD -P $PORT -G -E -R -c -x '^(mysql|db1|db2)'
mysql是MyISAM存储引擎

描述:
凌晨03:00执行脚本备份,几分钟后应用报错无法连接数据库,查看show processlist基本上大量的Waiting for table flush(大部分是select)和少量的Waiting for global read lock,重点筛选了执行备份的用户backup;

56793 backup 127.0.0.1:39481 NULL Query 3671 Waiting for table flush FLUSH TABLES WITH READ LOCK
Time 3671,很明显是被某大查询阻塞了,使用cat list.txt |awk '{if($6>3671) print $0}'筛选大于3671的线程,果然有一条记录
46109 app1 *.*.*.*:25545 db_name Query 13626 Sending data /* dynamic native SQL query */ SELECT ...
执行了13626/3600=3.7多个小时;从进程的id也可以看出,备份线程的id是56793,而该查询的id是46109的确是早于备份线程的id;并且状态是sending data,也就是说FTWRL被该句查询阻塞了。

疑问:既然大查询早于备份线程,为什么在执行备份时(加FTWRL前)show processlist,没有退出备份?默认是大于60s会终止备份