摘要：MDL鎖檢視讓一線運維人員清晰地檢視資料庫各session持有和等待的元資料鎖資訊，從而找出資料庫MDL鎖等待的根因，準確地進行下一步決策。

當多使用者共同存取資料時，資料庫中就會產生多個事務同時存取同一資料的情況。若不控制這種併發操作，資料庫的一致性就會被破壞。這種情況下，加鎖是實現資料庫併發控制的關鍵技術。

舉個例子，加鎖後事務就對該資料物件有了一定的控制，在事務釋放鎖之前，其他的事務不能對此資料物件進行更新操作。

MySQL從 5.5版本開始引入MDL鎖（即元資料鎖），MDL鎖主要為了保證元資料的一致性（主要是保證DDL操作與DML操作之間的一致性），用於處理不同執行緒操作同一元資料物件的同步與互斥問題，在各個業務場景中會十分頻繁地使用到。

具體而言，MySQL引入MDL鎖可以解決如下問題：一是事務隔離問題，比如在可重複讀隔離級別下，會話A在2次查詢期間，會話B對錶結構做了修改，2次查詢結果就會不一致，無法滿足可重複讀的要求。二是資料複製問題，比如會話A執行了多條更新語句期間，另外一個會話B做了表結構變更並且先提交，就會導致slave在重做時，先重做alter，再重做update時就會出現複製錯誤的現象。

MDL鎖檢視，一目瞭然元資料鎖問題

社群版MySQL無法獲取表MDL鎖的詳細資訊，當客戶遇到類似“Waiting for metadata lock”的問題而阻塞DML或DDL後，由於無法確定各session之間的關聯，往往無從下手，複雜情況下，只能重啟例項，從而增加解決問題的成本，對業務產生較大影響。

而且在業務場景較複雜的情況下，一旦涉及對資料庫元資料的互斥操作（如DDL、LOCK Table等），此類問題便會頻繁發生，給一線運維和客戶帶來很大的困擾。

針對以上痛點，華為雲資料庫MySQL在充分調研核心的基礎上，推出了MDL鎖檢視特性，可以清晰檢視資料庫各session持有和等待的元資料鎖資訊，方便現網運維進行問題定位，有效進行系統診斷，幫助客戶更好地優化自身業務。

MDL鎖檢視以系統表的形式呈現，該表位於INFORMATION_SCHEMA，表名：METADATA_LOCK_INFO，表結構如下：

MDL鎖檢視主要由7個欄位組成，各欄位詳情為：

• THREAD_ID：session的ID，即會話ID
• LOCK_STATUS：MDL鎖的狀態，主要分為PENDING和GRANTED兩種，分別表示session正在等待該MDL鎖和session已獲得該MDL鎖
• LOCK_MODE：加鎖的模式，如MDL_SHARED 、MDL_EXCLUSIVE 、MDL_SHARED_READ、MDL_SHARED_WRITE等
• LOCK_TYPE：MDL鎖的型別，如Table metadata lock、Schema metadata lock、Global read lock、Tablespace lock等
• LOCK_DURATION：MDL鎖的範圍，有三種取值：MDL_STATEMENT、MDL_TRANSACTION、MDL_EXPLICIT，分別表示語句級別、事務級別、global級別
• TABLE_SCHEMA：資料庫名，對於部分global級別的MDL鎖，該值為空
• TABLE_NAME：表名，對於部分global級別的MDL鎖，該值為空

MDL鎖檢視好在哪？

下面通過兩則案例來對MDL鎖檢視進行進一步的說明。

場景一：長時間未提交事務，阻塞DDL，繼而阻塞所有同表的操作

客戶發現表t2的truncate一直被阻塞後，業務流程中對錶t2的select操作也全部被阻塞。DDL被阻塞後，客戶立刻執行show processlist：

但是通過processlist資訊，只能看到session 4執行truncate操作時被其他session持有的table metadata lock阻塞，session 5執行select操作時也同樣被阻塞，無法確定哪個session阻塞了session 4和session 5。此時，如果盲目的去kill其他session（2或3）會給線上業務帶來很大風險，因此只能等待其他session釋放該MDL鎖。

而當客戶引入MDL鎖檢視後，執行SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO:

結合show processlist的結果，從元資料鎖檢視中可以明顯看出，session 4 pending在表t2的metadata lock，session 3持有表t2的metadata lock，該MDL鎖為事務級別，只要session 3的事務不提交，session 4便會一直阻塞。因此，客戶只需要在session 3中執行commit或kill session 3，便可以讓業務繼續執行。

場景二：長時間持有MDL鎖，導致全備失敗

客戶例項最近幾次全備均失敗，但是業務表現似乎正常，而且最近系統業務量不高，未出現明顯問題。運維團隊發現全備被阻塞後，立刻show processlist，發現有多個活躍的使用者session：

全備是基於xtrabackup，在執行真正的備份之前需要執行lock tables for backup，但從show processlist中只能看到：lock tables for backup時一直被某個MDL鎖阻塞，全備超時失敗；客戶的多個session業務量很小，都處於sleep狀態，於是客戶繼續執行show open tables where in_use >=1：

發現有個表t1始終處於in use狀態，所以猜測是使用者某個session持有了該表t1的MDL鎖未釋放，導致lock tables for backup等待超時。但是結合show processlist仍然無法確定是哪個session持有表t1的MDL鎖，想讓全備執行成功，只能通知客戶逐一斷連session或者重啟例項。

引入MDL鎖檢視後，客戶執行SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO:

結合show processlist的結果，從元資料鎖檢視中可以明顯看出，session 4 pending在全域性backup lock上；session 2持有全域性的backup lock，該MDL鎖型別為MDL_EXPLICIT，global級別。因此，客戶只需要在session 2顯式呼叫unlock tables釋放鎖或者kill session 2即可讓業務繼續執行。

通過以上兩個案例，MDL鎖檢視的重要性不言而喻，它可以讓客戶和一線運維人員清晰地檢視資料庫各session持有和等待的元資料鎖資訊，從而找出資料庫MDL鎖等待的根因，準確地進行下一步決策，有效降低對業務的影響。

華為雲資料庫MySQL在828企業上雲節期間，還有眾多優惠活動，體驗MDL鎖檢視的最佳時機。

相關推薦