MDL鎖視圖主要由7個(gè)字段組成,各字段詳情為:

?THREAD_ID:session的ID,即會(huì)話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鎖的類(lèi)型,如Table metadata lock、Schema metadata lock、Global read lock、Tablespace lock等

?LOCK_DURATION:MDL鎖的范圍,有三種取值:MDL_STATEMENT、MDL_TRANSACTION、MDL_EXPLICIT,分別表示語(yǔ)句級(jí)別、事務(wù)級(jí)別、global級(jí)別

?TABLE_SCHEMA:數(shù)據(jù)庫(kù)名,對(duì)于部分global級(jí)別的MDL鎖,該值為空

?TABLE_NAME:表名,對(duì)于部分global級(jí)別的MDL鎖,該值為空

MDL鎖視圖好在哪?

下面通過(guò)兩則案例來(lái)對(duì)MDL鎖視圖進(jìn)行進(jìn)一步的說(shuō)明。

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

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

      但是通過(guò)processlist信息,只能看到session 4執(zhí)行truncate操作時(shí)被其他session持有的table metadata lock阻塞,session 5執(zhí)行select操作時(shí)也同樣被阻塞,無(wú)法確定哪個(gè)session阻塞了session 4和session 5。此時(shí),如果盲目的去kill其他session(2或3)會(huì)給線上業(yè)務(wù)帶來(lái)很大風(fēng)險(xiǎn),因此只能等待其他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ù)級(jí)別,只要session 3的事務(wù)不提交,session 4便會(huì)一直阻塞。因此,客戶只需要在session 3中執(zhí)行commit或kill session 3,便可以讓業(yè)務(wù)繼續(xù)運(yùn)行。

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

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

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

      發(fā)現(xiàn)有個(gè)表t1始終處于in use狀態(tài),所以猜測(cè)是用戶某個(gè)session持有了該表t1的MDL鎖未釋放,導(dǎo)致lock tables for backup等待超時(shí)。但是結(jié)合show processlist仍然無(wú)法確定是哪個(gè)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鎖類(lèi)型為MDL_EXPLICIT,global級(jí)別。因此,客戶只需要在session 2顯式調(diào)用unlock tables釋放鎖或者kill session 2即可讓業(yè)務(wù)繼續(xù)運(yùn)行。

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

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

xiesc