mysql metadata lock锁

 很多情况下,很多问题从理论上或者管理上而言都是可以避免或者说很好解决的,但是一旦涉及到现实由于管理或者协调或者规范执行的不够到位,就会出现各种各样本不该出现的问题,这些问题的通常在生产环境并不会出现,但是现实是无论在任何环节出现,都得去找到解决方法,很多时候原因是一部分,预防措施也是一部分,但解决方法也是必须的,因为不可能跟所有的开发人员说你按照我说的做就没有问题了,因为总会有人疏忽了或者忽视了。前两天,测试环境升级脚本,跑到一半就报锁超时了,好几次后测试让协助而解决下。看了下,是个truncate操作在获取metadata lock,这个环境很复杂,有十来个应用连接着,有些是直接从仿真线路接进来的,测试、开发也都不想把应用停了,不然折腾太麻烦。默认该环境的锁超时时间是60s,同时设置了非autocommit,有个查询被truncate表的应用(这是后来知道的)不停的在查询该表,因为查询也需要metadata lock,除非commit或者rollback。在解决的过程中,最大的技术问题在于Mysql 5.7之前mysql原生无法看到metadata lock的阻塞者信息,导致逐个应用确认花费了时间(对于5.7的metadata_locks一直是有印象的,但发现5.6没有),但开发也不知道到底哪些应用会查询或者DML该表。最后临时性将autocommit设置为1,同时把锁超时时间设置为3600秒,两分钟后升级完过去。在mysql 5.7开始,可通过下述方法查询Metadata lock的持有者和阻塞者:UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME ='global_instrumentation';UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME ='wait/lock/metadata/sql/mdl';
SELECT ml.*,thr.* FROM `metadata_locks` ml,threads thr
WHERE ml.`OWNER_THREAD_ID` = thr.`THREAD_ID`;后来查了下,mysql 5.6有人开发了个mysql-plugin-mdl-info插件,可以查看类似信息。

相关内容推荐