1.問題
mysqldumpのバックアップデータを使用する場合は、show PROCESSLISTは時々テーブルのフラッシュを待っている多数の参照、mysqldumpが立ち往生。そして、クエリをもたらす可能性も立ち往生しています。
場合は、バックアップを実行することである：mysqldumpを-uroot -p --singleトランザクション--masterデータ= 2 --set-GTIDパージ= OFF TESTDB> /tmp/testdb.sql
そして、PROCESSLISTを示しています。
mysqldumpをスレッドがすぐにCtrl + Cを殺されました。すべてのテーブルのフラッシュの状態を待っている間に後が、姿を消しました。これは幸運で、SQLのない大規模なアプリケーションがブロックされていないがありました。mysqlの自身が正常に戻りました。Metは前に一度、最終的には、唯一の解決策は、mysqldを再起動します。
テーブルのフラッシュを待っているが過小評価すべきではないので、特別な注意が必要です！！！そして、MDL：メタデータは、特別な注意を必要とするとロックします。
テーブルのフラッシュを待っているの出現のための2つの理由
https://dev.mysql.com/doc/refman/5.6/en/general-thread-states.html
スレッドが実行される FLUSH TABLES と、すべてのスレッドがそのテーブルを閉じるために待っている、またはスレッドがテーブルの基礎となる構造が変化していると、それは新しい構造を得るために、テーブルを再度オープンする必要があることを通知しました。他のすべてのスレッドが問題にテーブルを閉じるまでただし、テーブルを再度開くために、それは待たなければなりません。
この通知は、別のスレッドが使用している場合に起こる FLUSH TABLES ：または問題のテーブルの上に次のステートメントの1 、 、 、 、 、または 。FLUSH TABLES tbl_nameALTER TABLERENAME TABLEREPAIR TABLEANALYZE TABLEOPTIMIZE TABLE
フラッシュテーブル文必要またはALTERテーブル、リネームテーブル、修理テーブルは、テーブルを分析し、最適化テーブルのテーブルのようなDDLステートメントが閉じられる必要があり、その後、テーブルを再度開き、
これらの表には、そこに大きなトランザクションを再実行することができ、またはロックされている、ように閉じられた表にすることはできませんので、状況があった：表のフラッシュを待っています
言い換えれば、あなたはフラッシュテーブルのスレッドを実行する必要があり、何らかの理由で近くのテーブル、フラッシュテーブルを完了することができないので、テーブルのフラッシュを待っていることはできません。
3.フラッシュmysqldumpを引き起こしたが、テーブルを待っを回避する方法
--masterデータ[=＃]
これは、バイナリログの位置とファイル名が出力に追加されます。1に等しい場合は、変更マスタとしてそれを印刷します
コマンド; 2に等しい場合、そのコマンドは、コメント記号を付けられます。このオプションがない限り、--lock-すべてのテーブルをオンにします
--single-トランザクションがあまりにも指定されている（この場合、グローバルリードロックはダンプの最初に短い時間を取られています。
--single-トランザクション以下）について読むことを忘れないでください。すべての場合において、ログ上の任意のアクションは、ダンプの正確な瞬間に起こるでしょう。
オプションは自動的に--lock-tablesをオフにします。
一緒にmysqldumpを--singelトランザクションオプションと--master-データと：
1）フラッシュのテーブルを実行する必要があります!!!!
2）読み込みロックでFLUSH TABLESを実行する必要!!!
そして、ここでフラッシュテーブルがする可能性があるのです大きなトランザクション、スロークエリまたはロックも、テーブルのフラッシュを待って、その結果、立ち往生するの!!!!
通常、--single-transacationと一緒に構築するために、マスターコピーから--master-データ。それ以外の場合は、一般的に--master-dataオプションを使用しません。実際には、あなたがxtrabackupバックアップコピーからのショットを呼び出すために使用することができ、問題は存在しません。
だから、--single-transacationと--master-dataオプションでの使用は避けてくださいにテーブルのフラッシュの問題やニーズにmysqldumpをリード待ちを避けるために！最も安全な方法は、唯一の--single-transactionオプションを使用することです。
テーブルのフラッシュの問題結果を待っている4。
フラッシュテーブルは、テーブルのフラッシュの状態のためにそこに待っていることでしょう完了することができない、この時間は、テーブルには、select文の実行がブロックされる場合でも、フラッシュでした！！！もちろん、他のテーブルはまだ正常なを選択することができます。
テーブルフラッシュ処理方法を待って5
待機中は、テーブルのためのフラッシュが発生した場合、我々は一般的に待っている生きているか、それらの遅いクエリがフラッシュテーブルにつながるロックのテーブルを見つける必要があるとテーブル閉じることはできません。そして、できるスレッドを殺すが、どのように正確に位置決めすることは、挑戦、特に本番環境では、あなたがショーのPROCESSLISTは、多数のスレッドを参照してください使用しています。ダズル、そしてどのようにすべての突然の問題を見つけるの？
他のスレッドの例テーブルのフラッシュ待ち状態に遅いクエリを引き起こしました：
あなたは、時間値PROCESSLIST大きなスレッドでショーを見ることができます。次にキルをオフに確認するためにスクリーニングしました。ルールの時間の種類は、この列の値は、スレッドブロックされたスレッドよりも高くなければならないです。フィルタは、レコードをたくさんすることができます。
ロックテーブル内の他のスレッドの場合には、テーブルのフラッシュの状態の期限待機をお読みください。
このセッションでは、スリープ状態であってもよいが、それはで\ショーエンジンInnoDBのステータス出力情報Gコマンドでは表示されません。IN_USE> = 1オープンテーブルがショーの場合であっても、見つけることができますが、テーブルがライブロックであるということですが、特定のスレッド（接続）を見つけることができなかった、実際には、この問題は頭痛の種です。innotopスレッド17が見つけることができるであるスレッド17テストテーブルをロックするために、以下に示すようしかし、このツールは、ターゲットをinntopことができます。工欲善其事必先利其器いわゆる！
参考：https://www.cnblogs.com/kerrycode/p/7388968.html