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锁的类型,如Table metadata 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等待超时。但是结合show processlist仍然无法确定是哪个session持有表t1的MDL锁,想让全备执行成功,只能通知客户逐一断连session或者重启实例。
引入MDL锁视图后,客户执行SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO:
结合show processlist的结果,从元数据锁视图中可以明显看出,session 4 pending在全局backup lock上;session 2持有全局的backup lock,该MDL锁类型为MDL_EXPLICIT,global级别。因此,客户只需要在session 2显式调用unlock tables释放锁或者kill session 2即可让业务继续运行。
通过以上两个案例,MDL锁视图的重要性不言而喻,它可以让客户和一线运维人员清晰地查看数据库各session持有和等待的元数据锁信息,从而找出数据库MDL锁等待的根因,准确地进行下一步决策,有效降低对业务的影响。
欲了解更多详情,敬请前往华为云官网:产品——基础服务——数据库——云数据库MySQL。
