華為云MySQL新增MDL鎖視圖特性，清晰查看各session元數(shù)據(jù)鎖信息

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

針對以上痛點,華為云數(shù)據(jù)庫MySQL在充分調(diào)研內(nèi)核的基礎(chǔ)上,推出了MDL鎖視圖特性,可以清晰查看數(shù)據(jù)庫各session持有和等待的元數(shù)據(jù)鎖信息,方便現(xiàn)網(wǎng)運維進行問題定位,有效進行系統(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鎖的類型,如Tablemetadata 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鎖視圖進行進一步的說明。

場景一:長時間未提交事務(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ù)運行。

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

客戶實例最近幾次全備均失敗,但是業(yè)務(wù)表現(xiàn)似乎正常,而且最近系統(tǒng)業(yè)務(wù)量不高,未出現(xià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é)合showprocesslist仍然無法確定是哪個session持有表t1的MDL鎖,想讓全備執(zhí)行成功,只能通知客戶逐一斷連session或者重啟實例。

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

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

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

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

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責(zé)任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。