Using Mydumper backup occurs waiting for table flush, which causes all threads to be unreadable and write
Version Mydumper 0.9.1
OS centos6.6 x86_64
MySQL 5.6.25-log
Mydumper backup option Mydumper-h $HOST-u $USER-P $PASSWORD-P $PORT-G-e-r-c-x ' ^ (MYSQL|DB1|DB2) '
MySQL is the MyISAM storage engine
Describe:
03:00 perform a script backup, a few minutes after the application error cannot connect to the database, view show processlist basically a large number of waiting for table flush (mostly Select) and a small amount of waiting for global read Lock, which focuses on filtering the user backup for performing backups;
56793backup127.0.0.1:39481nullquery3671waiting for table Flushflush TABLES with READ LOCK
Time 3671, obviously blocked by a large query, using cat List.txt |awk ' {if ($6>3671) print $} ' filter more than 3671 threads, there is a record
46109app1*.*.*.*:25545db_namequery13626sending data/* Dynamic Native SQL query */SELECT ...
13626/3600=3.7 is executed for multiple hours; from the ID of the process, the ID of the backup thread is 56793, and the ID of the query is 46109, which is indeed earlier than the backup thread's ID, and the state is sending data, which means FTWRL is blocked by the query.
Question: Since the large query is earlier than the backup thread, why did the backup (before adding FTWRL) show Processlist do not exit the backup? Default is greater than 60s will terminate the backup
Mydumper backup occurs waiting for table flush