synch/cond/sql/MDL_context::COND_wait_status - Amazon Aurora

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

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 指出有執行緒正在等待資料表中繼資料鎖定。在某些情況下,一個工作階段對資料表保有中繼資料鎖定,而另一個工作階段嘗試對同一資料表取得相同的鎖定。在這類情況下,第二個工作階段會等待 synch/cond/sql/MDL_context::COND_wait_status 等待事件。

MySQL 使用中繼資料鎖定來管理資料庫物件的並行存取,並確保資料一致性。中繼資料鎖定適用於資料表、結構描述、排程事件、資料表空間,以及使用 get_lock 函數和預存程式取得的使用者鎖定。預存程式包含程序、函數和觸發程序。如需詳細資訊,請參閱 MySQL 文件中的中繼資料鎖定

MySQL 程序清單顯示這個工作階段處於狀態 waiting for metadata lock 中。在績效詳情中,如果 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 事件比平時更常出現時,可能表示有效能問題,典型原因包括:

長時間執行的交易

一個或多個交易正在修改大量的資料,並對資料表保留鎖定很長一段時間。

交易閒置

一個或多個交易保持開啟狀態很長一段時間,沒有進行遞交或復原。

大型表格上的 DDL 陳述式

一或多個資料定義語言 (DDL) 陳述式,例如 ALTER TABLE 命令,已在非常大的資料表上執行。

明確資料表鎖定

未及時釋放的資料表上有明確的鎖定。例如,應用程式可能會不當地執行 LOCK TABLE 陳述式。

動作

我們會建議不同的動作,取決於等待事件的原因,以及 Aurora MySQL 資料庫叢集的版本。

識別造成事件的工作階段和查詢

您可以使用績效詳情來顯示 synch/cond/sql/MDL_context::COND_wait_status 等待事件所封鎖的查詢。不過,若要識別封鎖工作階段,請從資料庫叢集上的 performance_schemainformation_schema 查詢中繼資料表。

通常,具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的,則等待事件可能是可以接受的。如果效能不是最佳的,則檢查資料庫在何處花費最多時間。查看造成最高負載的等待事件,並了解您是否可以最佳化資料庫和應用程式,以減少這些事件。

尋找負責高負載的 SQL 查詢
  1. 登入 AWS Management Console,開啟位於 https://console.aws.amazon.com/rds/ 的 Amazon RDS 主控台。

  2. 在導覽窗格中,選擇 Performance Insights (績效詳情)。

  3. 選擇資料庫執行個體。該資料庫執行個體的績效詳情儀表板即會出現。

  4. Database load (資料庫負載) 圖表中,選擇 Slice by wait (依等待建立配量)。

  5. 在頁面底端,選擇 Top SQL (最高 SQL)。

    此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸,請專注於這些陳述式。

如需使用績效詳情進行疑難排解的實用概觀,請參閱 AWS 資料庫部落格文章利用績效詳情分析 Amazon Aurora MySQL 工作負載

檢查是否有過去的活動

您可以洞察這個等待事件,以檢查其是否發生過。若要這樣做,請完成下列動作。

  • 檢查資料處理語言 (DML) 和 DDL 輸送量和延遲,以查看工作負載是否有任何變更。

    您可以使用績效詳情來尋找問題發生時等待此事件的查詢。此外,您也可以檢視接近問題發生時的查詢執行摘要。

  • 如果開啟資料庫叢集的稽核日誌或一般日誌,您可以檢查所有查詢是否在等待交易中涉及的物件 (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 交易與鎖定資訊