2

現在、アプリケーションがダウンする原因となった次の問題があります。私たちが行うすべてのクエリは「テーブル待ち」状態になり、そこにとどまり、MySQL サーバー接続が使い果たされます。

MySQL マニュアルに従って、問題を調査し、それが何を意味するかを学びました。

テーブル待ち、テーブル待ち

スレッドは、テーブルの基になる構造が変更され、新しい構造を取得するためにテーブルを再度開く必要があるという通知を受け取りました。ただし、テーブルを再度開くには、他のすべてのスレッドが問題のテーブルを閉じるまで待つ必要があります。

この通知は、別のスレッドが FLUSH TABLES を使用したか、問題のテーブルで次のいずれかのステートメントを使用した場合に発生します: FLUSH TABLES tbl_name、ALTER TABLE、RENAME TABLE、REPAIR TABLE、ANALYZE TABLE、または OPTIMIZE TABLE。

実行中のプロセスを SHOW PROCESSLIST で調べたところ、データ定義言語ステートメント、または上記のリストにあるステートメントは見つかりませんでした。

他に何が原因でしょうか？

4

2 に答える 2

1

今日も同じ問題があります。最後に、大きなクエリとバックアップ プロセスの同時実行が原因であることがわかりました。–master-data を指定した mysqldump により、テーブルのフラッシュ コマンドが発生する場合があります。この http://bugs.mysql.com/bug.php?id=35157を参照してください。

私の状況は次のとおりです。フラッシュコマンドは大きなクエリを待っていました。他のクエリは、テーブルのフラッシュ コマンドが完了するのを待っていたため、ブロックされました。大きなクエリが完了すると、すべてがうまくいきました。

ですから、その時点で大きなクエリが発生する可能性があると思います。

于 2014-10-01T09:35:35.643 に答える