synch/cond/sql/MDL_context::COND_wait_status
synch/cond/sql/MDL_context::COND_wait_status イベントは、テーブルメタデータロックに待機中のスレッドがあるときに発生します。
サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
-
Aurora MySQL バージョン 2 および 3
Context
イベント synch/cond/sql/MDL_context::COND_wait_status は、テーブルメタデータロックを待機中のスレッドがあることを示します。場合によっては、あるセッションがテーブルのメタデータロックを保持し、別のセッションが同じテーブルで同じロックを取得しようとする場合があります。このような場合、2 番目のセッションは synch/cond/sql/MDL_context::COND_wait_status 待機イベントで待機します。
MySQL は、メタデータロックを使用して、データベースオブジェクトへの同時アクセスを管理し、データの整合性を確保します。メタデータのロックは、get_lock 関数で取得したスケジュールされたイベント、テーブルスペース、ユーザーロックテーブル、および ストアドプログラムに適用されます。ストアドプログラムには、プロシージャ、関数、トリガーが含まれます。詳細については、MySQL ドキュメントのメタデータロック
MySQL プロセスリストは、このセッションを状態 waiting for metadata
lock で表示されます。Performance Insights では、Performance_schema がオンになっている場合、イベント synch/cond/sql/MDL_context::COND_wait_status が表示されます。
メタデータロックで待っているクエリのデフォルトタイムアウトは lock_wait_timeout パラメータ値に基づきます。デフォルトは 31,536,000 秒 (365 日) です。
さまざまな InnoDB ロックと競合を引き起こす可能性のあるロックの種類の詳細については、MySQL ドキュメントの InnoDB ロック
待ち時間増加の考えられる原因
synch/cond/sql/MDL_context::COND_wait_status イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。
- 実行時間が長いトランザクション
-
1 つ以上のトランザクションが大量のデータを変更し、非常に長い間テーブルのロックを保持しています。
- Idle トランザクション
-
1 つ以上のトランザクションは、コミットまたはロールバックされることなく、長い間開いたままです。
- 大きなテーブルの DDL ステートメント
-
1 つ以上のデータ定義ステートメント (DDL) ステートメント。
ALTER TABLEコマンドは、非常に大きなテーブルで実行されました。 - 明示的なテーブルロック
-
テーブルには、タイムリーに解放されない明示的なロックがあります。例えば、アプリケーションが実行されているとします。
LOCK TABLE不適切にステートメント。
アクション
待機イベントの原因と Aurora MySQL DB クラスターのバージョンに応じて、さまざまなアクションをお勧めします。
イベントの原因となるセッションとクエリを特定する
Performance Insights を使用して、synch/cond/sql/MDL_context::COND_wait_status 待機イベントによってブロックされたクエリを表示できます。ただし、ブロッキングセッションを特定するには、からメタデータテーブルをクエリします。performance_schemaそしてinformation_schemaDB クラスター上にあります。
通常、ロードが中程度から重大なデータベースには、待機イベントがあります。パフォーマンスが最適であれば、待機イベントは受け入れられる可能性があります。パフォーマンスが最適でない場合は、データベースが最も長い時間を費やしている場所を調べます。最も高いロードに寄与する待機イベントを調べて、データベースとアプリケーションを最適化してこれらのイベントを削減できるかどうかを調べます。
高ロードの原因となる SQL クエリを検索するには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
ナビゲーションペインで、[Performance Insights] を選択します。
-
DB インスタンスを選択します。この DB インスタンスに Performance Insights ダッシュボードが表示されます。
-
データベースロードで、待機でスライスを選択します。
-
ページの下部で トップ SQL を選択します。
グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。
Performance Insights を使用したトラブルシューティングの便利な概要については、AWS データベースブログ記事の Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析
過去のイベントをチェックする
この待機イベントについてのインサイトを取得して、過去のイベントが発生していないかどうかをチェックできます。そのためには、以下のアクションを実行します。
-
データ操作言語 (DML) と DDL のスループットとレイテンシーを調べて、ワークロードに変更があったかどうかをチェックします。
Performance Insights を使用して、問題発生時にこのイベントで待っているクエリを検索できます。また、発行時に実行されたクエリのダイジェストを表示することもできます。
-
DB クラスターの監査ログまたは一般ログがオンになっている場合、待機中のトランザクションに含まれるオブジェクト (schema.table) で実行されるすべてのクエリをチェックできます。また、トランザクションの前に実行が完了したクエリをチェックすることもできます。
過去のイベントのトラブルシューティングに使用できる情報は限られています。これらのチェックを実行しても、どのオブジェクトが情報を待っているのかは示されません。ただし、イベント時にロードが大きいテーブルや、発行時に競合の原因となる頻繁に操作される一連の行を特定できます。この情報を使用して、テスト環境で問題を再現し、その原因に関するインサイトを使用できます。
Aurora MySQL バージョン 2 でクエリを実行する
Aurora MySQL バージョン 2 の場合、performance_schema テーブルないし sys ビューに対してクエリを実行して、ブロックされたセッションを直接識別できます。。例は、ブロックしているクエリとセッションを識別するため、テーブルにクエリを実行する方法を示しています。
次のプロセスリストの出力では、接続 ID 89 がメタデータロックを待っていて、TRUNCATE TABLE コマンドを実行しています。performance_schema テーブルないし sys スキーマビューのクエリの場合、出力が表示するブロッキングセッションは 76 です。
MySQL [(none)]> select @@version, @@aurora_version; +-----------+------------------+ | @@version | @@aurora_version | +-----------+------------------+ | 5.7.12 | 2.09.0 | +-----------+------------------+ 1 row in set (0.01 sec) MySQL [(none)]> show processlist; +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ | 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL | | 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL | | 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL | | 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL | | 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL | | 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL | | 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL | | 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL | | 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL | | 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL | | 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL | | 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL | | 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL | | 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL | | 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL | | 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist | | 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) | | 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 | +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ 18 rows in set (0.00 sec)
次に、performance_schema テーブルないし sys スキーマビューのクエリはブロッキングセッションが 76 であることを示します。
MySQL [(none)]> select * from sys.schema_table_lock_waits; +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ | object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection | +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ | sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 | +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ 1 row in set (0.00 sec)
ブロッキングセッションに応答する
セッションを特定する際、次のようなオプションが含まれます。
-
アプリケーションの所有者またはユーザーにお問い合わせください。
-
ブロッキングセッションがアイドル状態の場合は、ブロッキングセッションを終了することを検討してください。このアクションは、長いロールバックをトリガーする可能性があります。セッションの終了方法については、「セッションやクエリの終了」を参照してください。
ブロックトランザクションの識別の詳細については、MySQL ドキュメントのInnoDB トランザクションの使用と情報のロック
