MDL锁(Metadata Lock),即元数据锁。元数据指的是描述数据的数据,对数据及信息资源的描述性信息,在数据库中元数据即数据字典信息,包括db,table,function,procedure,trigger,event等。
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锁的类型,如Tablemetadata 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等待超时。但是结合showprocesslist仍然无法确定是哪个session持有表t1的MDL锁,想让全备执行成功,只能通知客户逐一断连session或者重启实例。
引入MDL锁视图后,客户执行SELECT*FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO:
结合showprocesslist的结果,从元数据锁视图中可以明显看出,session4 pending在全局backup lock上;session2持有全局的backup lock,该MDL锁类型为MDL_EXPLICIT,global级别。因此,客户只需要在session 2显式调用unlock tables释放锁或者killsession 2即可让业务继续运行。
通过以上两个案例,MDL锁视图的重要性不言而喻,它可以让客户和一线运维人员清晰地查看数据库各session持有和等待的元数据锁信息,从而找出数据库MDL锁等待的根因,准确地进行下一步决策,有效降低对业务的影响。
欲了解更多详情,敬请前往华为云官网:产品——基础服务——数据库——云数据库MySQL。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
