MDL鎖(Metadata Lock)，即元數(shù)據(jù)鎖。元數(shù)據(jù)指的是描述數(shù)據(jù)的數(shù)據(jù)，對數(shù)據(jù)及信息資源的描述性信息，在數(shù)據(jù)庫中元數(shù)據(jù)即數(shù)據(jù)字典信息，包括db，table，function，procedure，trigger，event等。

　　MySQL從 5.5版本開始引入MDL鎖，MDL鎖主要為了保證元數(shù)據(jù)的一致性(主要是保證DDL操作與DML操作之間的一致性)，用于處理不同線程操作同一元數(shù)據(jù)對象的同步與互斥問題，在各個業(yè)務(wù)場景中會十分頻繁地使用到。

　　具體而言，MySQL引入MDL鎖可以解決如下問題：一是事務(wù)隔離問題，比如在可重復(fù)讀隔離級別下，會話A在2次查詢期間，會話B對表結(jié)構(gòu)做了修改，2次查詢結(jié)果就會不一致，無法滿足可重復(fù)讀的要求。二是數(shù)據(jù)復(fù)制問題，比如會話A執(zhí)行了多條更新語句期間，另外一個會話B做了表結(jié)構(gòu)變更并且先提交，就會導(dǎo)致slave在重做時，先重做alter，再重做update時就會出現(xiàn)復(fù)制錯誤的現(xiàn)象。

　　何為MDL鎖視圖?

　　社區(qū)版MySQL無法獲取表MDL鎖的詳細(xì)信息，當(dāng)客戶遇到類似“Waiting for metadata lock”的問題而阻塞DML或DDL后，由于無法確定各session之間的關(guān)聯(lián)，往往無從下手，復(fù)雜情況下，只能重啟實(shí)例，從而增加解決問題的成本，對業(yè)務(wù)產(chǎn)生較大影響。而且在業(yè)務(wù)場景較復(fù)雜的情況下，一旦涉及對數(shù)據(jù)庫元數(shù)據(jù)的互斥操作(如DDL、LOCK Table等)，此類問題便會頻繁發(fā)生，給一線運(yùn)維和客戶帶來很大的困擾。

　　針對以上痛點(diǎn)，華為云數(shù)據(jù)庫MySQL在充分調(diào)研內(nèi)核的基礎(chǔ)上，推出了MDL鎖視圖特性，可以清晰查看數(shù)據(jù)庫各session持有和等待的元數(shù)據(jù)鎖信息，方便現(xiàn)網(wǎng)運(yùn)維進(jìn)行問題定位，有效進(jìn)行系統(tǒng)診斷，幫助客戶更好地優(yōu)化自身業(yè)務(wù)。

　　MDL鎖視圖以系統(tǒng)表的形式呈現(xiàn)，該表位于INFORMATION_SCHEMA，表名：METADATA_LOCK_INFO，表結(jié)構(gòu)如下：

　　MDL鎖視圖主要由7個字段組成，各字段詳情為：

　　• THREAD_ID：session的ID，即會話ID

　　• LOCK_STATUS：MDL鎖的狀態(tài)，主要分為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，分別表示語句級別、事務(wù)級別、global級別

　　• TABLE_SCHEMA：數(shù)據(jù)庫名，對于部分global級別的MDL鎖，該值為空

　　• TABLE_NAME：表名，對于部分global級別的MDL鎖，該值為空

　　MDL鎖視圖好在哪?

　　下面通過兩則案例來對MDL鎖視圖進(jìn)行進(jìn)一步的說明。

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

　　客戶發(fā)現(xiàn)表t2的truncate一直被阻塞后，業(yè)務(wù)流程中對表t2的select操作也全部被阻塞。DDL被阻塞后，客戶立刻執(zhí)行show processlist：

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

　　而當(dāng)客戶引入MDL鎖視圖后，執(zhí)行SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO:

　　結(jié)合show processlist的結(jié)果，從元數(shù)據(jù)鎖視圖中可以明顯看出，session 4 pending在表t2的metadata lock，session 3持有表t2的metadata lock，該MDL鎖為事務(wù)級別，只要session 3的事務(wù)不提交，session 4便會一直阻塞。因此，客戶只需要在session 3中執(zhí)行commit或kill session 3，便可以讓業(yè)務(wù)繼續(xù)運(yùn)行。

　　場景二：長時間持有MDL鎖，導(dǎo)致全備失敗

　　客戶實(shí)例最近幾次全備均失敗，但是業(yè)務(wù)表現(xiàn)似乎正常，而且最近系統(tǒng)業(yè)務(wù)量不高，未出現(xiàn)明顯問題。運(yùn)維團(tuán)隊發(fā)現(xiàn)全備被阻塞后，立刻show processlist，發(fā)現(xiàn)有多個活躍的用戶session：

　　全備是基于xtrabackup，在執(zhí)行真正的備份之前需要執(zhí)行l(wèi)ock tables for backup，但從show processlist中只能看到：lock tables for backup時一直被某個MDL鎖阻塞，全備超時失敗;客戶的多個session業(yè)務(wù)量很小，都處于sleep狀態(tài)，于是客戶繼續(xù)執(zhí)行show open tables where in_use >=1：

　　發(fā)現(xiàn)有個表t1始終處于in use狀態(tài)，所以猜測是用戶某個session持有了該表t1的MDL鎖未釋放，導(dǎo)致lock tables for backup等待超時。但是結(jié)合show processlist仍然無法確定是哪個session持有表t1的MDL鎖，想讓全備執(zhí)行成功，只能通知客戶逐一斷連session或者重啟實(shí)例。

　　引入MDL鎖視圖后，客戶執(zhí)行SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO:

　　結(jié)合show processlist的結(jié)果，從元數(shù)據(jù)鎖視圖中可以明顯看出，session 4 pending在全局backup lock上;session 2持有全局的backup lock，該MDL鎖類型為MDL_EXPLICIT，global級別。因此，客戶只需要在session 2顯式調(diào)用unlock tables釋放鎖或者kill session 2即可讓業(yè)務(wù)繼續(xù)運(yùn)行。

　　通過以上兩個案例，MDL鎖視圖的重要性不言而喻，它可以讓客戶和一線運(yùn)維人員清晰地查看數(shù)據(jù)庫各session持有和等待的元數(shù)據(jù)鎖信息，從而找出數(shù)據(jù)庫MDL鎖等待的根因，準(zhǔn)確地進(jìn)行下一步?jīng)Q策，有效降低對業(yè)務(wù)的影響。

　　欲了解更多詳情，敬請前往華為云官網(wǎng)：產(chǎn)品——基礎(chǔ)服務(wù)——數(shù)據(jù)庫——云數(shù)據(jù)庫MySQL。

特別提醒：本網(wǎng)內(nèi)容轉(zhuǎn)載自其他媒體，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點(diǎn)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實(shí)，對本文以及其中全部或者部分內(nèi)容、文字的真實(shí)性、完整性、及時性本站不作任何保證或承諾，并請自行核實(shí)相關(guān)內(nèi)容。本站不承擔(dān)此類作品侵權(quán)行為的直接責(zé)任及連帶責(zé)任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請及時聯(lián)系我們，本站將會在24小時內(nèi)處理完畢。