L' --single-transactionoption de mysqldump fait un FLUSH TABLES WITH READ LOCKavant de démarrer la tâche de sauvegarde, mais uniquement sous certaines conditions. L'une de ces conditions est lorsque vous spécifiez également l' --master-dataoption.
Dans le code source, à partir mysql-5.6.19/client/mysqldump.cde la ligne 5797:
if ((opt_lock_all_tables || opt_master_data ||
(opt_single_transaction && flush_logs)) &&
do_flush_tables_read_lock(mysql))
goto err;
Pour obtenir un verrou solide sur les coordonnées binlog précises avant de commencer la transaction de lecture répétable, l' --master-dataoption déclenche l'obtention de ce verrou, puis le relâche une fois les coordonnées binlog obtenues.
En fait, mysqldumpfait un FLUSH TABLESsuivi d'un FLUSH TABLES WITH READ LOCKparce que faire les deux choses permet d'obtenir le verrou de lecture plus rapidement dans les cas où le vidage initial prend un certain temps.
...toutefois...
Dès qu'il a obtenu les coordonnées binlog, mysqldumpémet une UNLOCK TABLESinstruction, il ne devrait donc pas y avoir de blocage à la suite du vidage que vous avez commencé. Aucun thread ne doit non Waiting for table flushplus résulter de la transaction en cours mysqldump.
Lorsque vous voyez un thread dans l' Waiting for table flushétat, cela devrait signifier que l' FLUSH TABLES [WITH READ LOCK]instruction a été émise et était toujours en cours d'exécution au démarrage de la requête - la requête doit donc attendre le vidage de la table avant de pouvoir s'exécuter. Dans le cas de la liste de processus que vous avez publiée, mysqldumplit à partir de ce même tableau, et la requête est en cours d'exécution depuis un certain temps, mais les requêtes de blocage ne bloquent pas depuis si longtemps.
Tout cela suggère que quelque chose d'autre s'est produit.
Il y a un problème de longue date expliqué dans le bogue # 44884 avec le FLUSH TABLESfonctionnement interne. Je ne serais pas surpris si le problème persiste, je serais surpris si ce problème est jamais "résolu" car il s'agit d'un problème très complexe à résoudre - pratiquement impossible à résoudre véritablement dans un environnement à forte concurrence - et toute tentative de le réparer comporte un risque important de casser quelque chose d'autre ou de créer un comportement nouveau, différent et toujours indésirable.
Il semble probable que ce sera l'explication de ce que vous voyez.
Plus précisément:
si vous avez une requête de longue durée exécutée sur une table et émettez FLUSH TABLES, alors le FLUSH TABLESbloquera jusqu'à ce que la requête de longue durée se termine.
en outre, toutes les requêtes qui commencent après l' FLUSH TABLESémission du sont bloquées jusqu'à ce que le FLUSH TABLESsoit terminé.
en outre, si vous supprimez la FLUSH TABLESrequête, les requêtes qui bloquent seront toujours bloquées sur la requête de longue durée d'origine, celle qui bloquait la FLUSH TABLESrequête, car même si la FLUSH TABLESrequête tuée ne s'est pas terminée, cette table (celle ou plus, impliqué dans la requête de longue durée) est toujours en cours de vidage, et ce vidage en attente va se produire dès que la requête de longue durée se termine - mais pas avant.
La conclusion probable ici est qu'un autre processus - peut-être un autre mysqldump, ou une requête mal avisée, ou un processus de surveillance mal écrit a tenté de vider une table.
Cette requête a ensuite été supprimée ou expirée par un mécanisme inconnu, mais ses séquelles ont persisté jusqu'à la mysqldumpfin de la lecture du tableau en question.
Vous pouvez répliquer cette condition en essayant FLUSH TABLESpendant qu'une requête de longue durée est en cours. Ensuite, lancez une autre requête, qui se bloquera. Tuez ensuite la FLUSH TABLESrequête, qui ne débloquera pas la dernière requête. Ensuite, supprimez la première requête ou laissez-la se terminer, et la requête finale s'exécutera avec succès.
Après coup, cela n'est pas lié:
Trx read view will not see trx with id >= 1252538405, sees < 1252538391
C'est normal, car le mysqldump --single-transactionproblème a START TRANSACTION WITH CONSISTENT SNAPSHOT, qui l'empêche de vider les données modifiées pendant le vidage. Sans cela, les coordonnées binlog obtenues au départ n'auraient aucun sens, car la --single-transactionne serait pas ce qu'elle prétend être. Cela ne devrait en aucun cas être lié au Waiting for table flushproblème, car cette transaction ne comporte évidemment aucun verrou.