MDL lock (Metadata Lock), i.e., the lock metadata. It refers to the metadata describes data, descriptive information and information resources of the data, i.e., data in database dictionary metadata information, including db, table, function, procedure, trigger, event and so on.
MySQL started to introduce MDL lock from the 5.5 version, the main MDL lock in order to ensure consistency of metadata (mainly to ensure consistency between DDL and DML operation operation), used to treat different threads manipulate the same metadata objects synchronization and mutual exclusion problems in various business scenarios will be very frequently used to.
Specifically, MySQL introduced MDL lock can solve the following problems: First, the transaction isolation problem, such as in the Repeatable Read isolation level, during the 2nd session A query session B on the table structure has been modified twice a query result It will be inconsistent, unable to meet the requirements of repeatable read. Second, data replication problems, such as A session during the execution of multiple update statements, another session B to do the table structure changes and to submit, will lead to slave in the redo to redo alter, update it again when redo phenomenon replication errors may occur.
What is MDL lock view?
MySQL Community Edition can not obtain detailed information table MDL lock after when customers experience a similar "Waiting for metadata lock" problems blocking DML or DDL, inability to determine the association between each session, often unable to start, difficult situations. You can only restart the instance, thereby increasing the cost to solve the problem, have a greater impact on the business. And in business scenarios more complex cases, when it comes to exclusive operation of the database metadata (such as DDL, LOCK Table, etc.), these problems will occur frequently, operation and maintenance and front-line customer a great deal of distress.
For more than pain point, Huawei's cloud database MySQL on the basis of full investigation kernel on the introduction of the MDL lock view properties, you can clearly see the database each session to hold and metadata lock message waiting facilitate existing network operation and maintenance locate problems, effectively system diagnostics to help customers better optimize their business.
MDL lock system views presented in the form of a table, the table is in the INFORMATION_SCHEMA, table name: METADATA_LOCK_INFO, the table structure is as follows:
MDL lock view consists of seven fields, each field details as follows:
- THREAD_ID : of the session ID, a session ID
- LOCK_STATUS : MDL lock status, and GRANTED PENDING divided into two kinds, respectively session is waiting to lock the MDL and MDL lock the session has been
- LOCK_MODE : locked mode, such as MDL_SHARED, MDL_EXCLUSIVE, MDL_SHARED_READ, MDL_SHARED_WRITE etc.
- Lock_type : the MDL type of lock, such as Table metadata lock, Schema metadata lock, Global read lock, Tablespace lock , etc.
- LOCK_DURATION : MDL lock range, there are three values: MDL_STATEMENT, MDL_TRANSACTION, MDL_EXPLICIT, respectively statement level, transaction level, global level
- TABLE_SCHEMA : database name, for some global-level lock MDL, the value is blank
- TABLE_NAME : table name, the MDL level for some global lock, the value is null
MDL lock view Fortunately, what?
Below for further explanation of the MDL lock view through two cases.
Scene One: long uncommitted transactions, blocking DDL, and then block all operations with tables
| T |
Session 2 |
Session 3 |
Session 4 |
Session 5 |
| T1 |
begin; select *from t1; |
|
||
| T2 |
begin; select *from t2; |
|
||
| T3 |
truncate table t2; (blocked) |
|
||
| T4 |
|
|
|
begin; select *from t2; (blocked) |
After the customer has been found to truncate table t2 is blocked, the business process to select the operating table t2 have all been blocked. DDL After being blocked, the customer immediately perform the show processlist:
But by processlist information, can only be seen when the session 4 to perform truncate operation is held by another session table metadata lock blocking, also blocked when the session 5 select operations, can not determine which session blocked session 4 and session 5. At this point, if blind to kill the other session (2 or 3) online business will bring great risks, and therefore can only wait for the other session MDL release the lock.
And when the customer views the introduction of MDL lock, execute SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO:
Results show processlist binding from the metadata will be apparent in view of the lock, session 4 pending metadata lock in table t2, session 3 holds metadata lock table t2, the MDL level locking for the transaction, the transaction is not as long as the session 3 submit, session 4 will have been blocked. Therefore, customers only need to perform commit or kill session in session 3 3, you can let the business continue to run.
Scene 2: long hold MDL lock, leading all equipment failure
| T |
Session 2 |
Session 3 |
Session 4 |
Session 5 |
| T1 |
lock tables t1 write; |
|
||
| T2 |
select *from t1; |
insert into t2; |
select *from t3 |
|
| T3 |
Lock tables for backup; (blocked) |
|
||
| T4 |
|
begin; select *from t2; |
|
begin; insert into t3; |
客户实例最近几次全备均失败，但是业务表现似乎正常，而且最近系统业务量不高，未出现明显问题。运维团队发现全备被阻塞后，立刻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锁等待的根因，准确地进行下一步决策，有效降低对业务的影响。
