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鎖視圖進行進一步的說明。

image.png

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

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

image.png

      但是通過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:

image.png

      結(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ù)運行。

image.png

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

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

image.png

       全備是基于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:

image.png

      發(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或者重啟實例。

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

image.png

       結(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ù)運行。

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

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

image.png
分享到

xiesc

相關(guān)推薦