La --single-transactionpossibilità di mysqldump non fare una FLUSH TABLES WITH READ LOCKprima di iniziare il processo di backup , ma solo a determinate condizioni. Una di queste condizioni è quando si specifica anche l' --master-dataopzione.
Nel codice sorgente, dalla mysql-5.6.19/client/mysqldump.criga 5797:
if ((opt_lock_all_tables || opt_master_data ||
(opt_single_transaction && flush_logs)) &&
do_flush_tables_read_lock(mysql))
goto err;
Per ottenere un blocco solido sulle coordinate binlog precise prima di iniziare la transazione di lettura ripetibile, l' --master-dataopzione attiva questo blocco che deve essere ottenuto e quindi rilasciato una volta ottenute le coordinate binlog.
In effetti, mysqldumpfa FLUSH TABLESseguito da a FLUSH TABLES WITH READ LOCKperché fare entrambe le cose consente di ottenere il blocco della lettura più velocemente nei casi in cui il flush iniziale richiede del tempo.
...però...
Non appena ha ottenuto le coordinate del binlog, mysqldumpemette UNLOCK TABLESun'istruzione, quindi non dovrebbe esserci nulla che blocchi a causa del flush che hai iniziato. Né alcun thread dovrebbe essere Waiting for table flushil risultato della transazione che mysqldumpsta trattenendo.
Quando vedi un thread nello Waiting for table flushstato, ciò dovrebbe significare che l' FLUSH TABLES [WITH READ LOCK]istruzione è stata emessa ed era ancora in esecuzione all'avvio della query, quindi la query deve attendere lo svuotamento della tabella, prima che possa essere eseguita. Nel caso dell'elenco processi che hai pubblicato, mysqldumpsta leggendo da questa stessa tabella e la query è in esecuzione da un po ', ma le query di blocco non sono state bloccate per così tanto tempo.
Tutto ciò suggerisce che è successo qualcos'altro.
C'è un problema di vecchia data spiegato nel Bug # 44884 con il modo in cui FLUSH TABLESfunziona, internamente. Non sarei sorpreso se il problema persiste, sarei sorpreso se questo problema fosse mai "risolto" perché è un problema molto complesso da risolvere - praticamente impossibile da risolvere veramente in un ambiente ad alta concorrenza - e qualsiasi tentativo di risolverlo comporta un rischio significativo di rompere qualcos'altro o di creare un comportamento nuovo, diverso e ancora indesiderabile.
Sembra probabile che questa sarà la spiegazione di ciò che stai vedendo.
In particolare:
se si dispone di una query di lunga durata in esecuzione su una tabella e si verifica un problema FLUSH TABLES, il FLUSH TABLESblocco verrà eseguito fino al completamento della query di lunga durata.
inoltre, tutte le query che iniziano dopo l' FLUSH TABLESemissione verranno bloccate fino al FLUSH TABLEScompletamento.
Inoltre, se si uccide FLUSH TABLESl'interrogazione, le query che stanno bloccando saranno ancora bloccare sull'originale query di lunga durata, quella che stava bloccando l' FLUSH TABLESinterrogazione, perché anche se l'ucciso FLUSH TABLESquery non ha finito, quel tavolo (l'uno, o inoltre, coinvolto con la query di lunga durata) è ancora in fase di svuotamento e tale svuotamento in sospeso avverrà non appena termina la query di lunga durata, ma non prima.
La probabile conclusione qui è che un altro processo - forse un altro mysqldump, o una query sconsiderata, o un processo di monitoraggio scritto male ha tentato di cancellare una tabella.
Quella query è stata successivamente eliminata o scaduta da un meccanismo sconosciuto, ma i suoi effetti collaterali sono rimasti fino al mysqldumptermine della lettura dalla tabella in questione.
È possibile replicare questa condizione provando FLUSH TABLESmentre è in corso una query di lunga durata. Quindi avviare un'altra query, che verrà bloccata. Quindi uccidi la FLUSH TABLESquery, che non sbloccherà l'ultima query. Quindi uccidere la prima query o lasciarla terminare e la query finale verrà eseguita correttamente.
Come ripensamento, questo non è correlato:
Trx read view will not see trx with id >= 1252538405, sees < 1252538391
È normale, perché mysqldump --single-transactionemette a START TRANSACTION WITH CONSISTENT SNAPSHOT, che gli impedisce di scaricare i dati che sono stati modificati mentre era in corso il dump. Senza questo, le coordinate binlog ottenute all'inizio sarebbero prive di significato, dal momento --single-transactionche non sarebbero quelle che afferma di essere. Ciò non dovrebbe in alcun modo essere correlato al Waiting for table flushproblema, poiché questa transazione ovviamente non ha vincoli.