记一次MDL锁导致的Mysql主从复制延迟，Waiting for dependent transaction to commit，Waiting for table metadata lock

题外话

在生产环境中，为了更好性能，经常会见到主节点写，从节点只读的情况，即读写分离；本文记录了读写分离时遇到的一特殊主从复制延迟。

一、主从复制延迟现象

收到主从复制延迟告警

告警内容：(敏感信息做了屏蔽)

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 13754354
              Relay_Log_Space: 14690374
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: xxxx
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 53153306
                  Master_UUID: xxxxxx-3c7f-11e8-969a-005056a16d70
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Waiting for dependent transaction to commit
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: xxxxxxx-3c7f-11e8-969a-005056a16d70:153908122-204096262
            Executed_Gtid_Set: xxxxxxx-3c7f-11e8-969a-005056a16d70:1-204095398

收到告警后，立即登陆从库：
在从库show slave status查看到的现象和收到的告警内容一样。

二、主从复制延迟分析

从告警内容可以明显的观察到，主从复制确实有延迟，而且此时从节点服务器CPU占用比较高，所以用show processlist查看从节点有正在执行的操作：

在这里插入图片描述

可以看到有很多select语句执行了很长时间了（这种语句真坑啊），猜想会不会是这些select语句造成的，再次检查发现一个细节：
在这里插入图片描述
这是Mysql主从复制进程,很明显的看到Waiting for table metadata lock，后面是一个create index创建索引的语句，由此可以判断发生了MDL（元数据锁）；过程为主节点创建索引，从节点回放此创建索引操作时，被上面的select 语句阻塞，导致了主从复制延迟。

PS：什么是MDL元数据锁？
MySQL5.5版本引入了MDL锁（metadata lock），用于解决或者保证DDL操作与DML操作之间的一致性。具体可参考我转载的一篇博文:
https://blog.csdn.net/Tah_001/article/details/107931747

三、问题处理

定位到原因后,与业务系统相关人员沟通,可以直接把上面的慢查询select语句直接kill掉,kill掉相关select语句后,MDL锁释放，主从复制恢复正常.

扫描二维码关注公众号，回复： 11759865 查看本文章

四、总结

可能出现主从复制延迟的情况：

1.网络延迟较高，导致备库的IO线程等待。
2.备库IO硬件条件较主库差，IO能力不足。
3.主库执行出现大事务，导致出现延时的突刺。
4.备库未开启多线程复制，sql apply存在瓶颈。
5.备机当前会话存在元数据锁等待。
6.无主键表更新。

改进:
1.找出业务系统的慢查询语句,要求整改.只读节点不能用作语句测试.
2.创建索引属于DDL语句,使用pt工具或在业务低峰期创建.

哎哟，不错噢！ - - - - - - 欢迎指出有误的地方以及补充更好的方法