MySQL:由USE DB堵塞故障引发的思考

  • 时间:
  • 浏览:0

其中EXCLUSIVE如果 大伙说的MDL_EXCLUSIVE(X)它随便说说 所处当前所处堵塞

3、SELECT * FROM A

其STATE为 Waiting for table metadata lock

表现如下:

关于sending data这种 状况随便说说 都可不可以 代表有些有些含义,从我现有的对的了解,这是MYSQL上层对SELECT类型说说的类事说说在INNODB层和MYSQL层进行数据交互的从前另2个 统称,有些有些突然出显它的意味着着涵盖:

信息分析

这麼 这种 状况就和SHOW TABLE STATUS[like 'A']被堵塞的状况一模一样了,也意味着着MDL 锁不兼容造成的。

这种 点也是我从前我不在 乎 的,也是本案列中花时间最多的地方,前文意味着着分析过要让SHOW TABLE STATUS[like 'A']这种 只会上MDL_SHARED_HIGH_PRIO(SH) MDL LOCK的说说堵塞在MDL LOCK上只有五种意味着着那如果 A表上了MDL_EXCLUSIVE(X)。

GITD关闭RR隔离级别

使用脚本:

这麼 我结束英语 怀疑这种 DDL说说在说说结束英语 以完会对A表上MDL_EXCLUSIVE(X) ,有之前 进行实际测试不在 所料随便说说 是从前的如下:

遇到故障,大伙往往想的是怎么可以 除理这种 故障,而都是从故障的根本去思考突然出显这种 故障的意味着着?从前的结果,只有使大伙得到了鱼,选择选择离开了渔。今天,大伙就来分享另2个 由USE DB堵塞故障引发的思考案例。

有了前面的分析这麼 大伙都可不可以 梳理这种 故障所处的意味着着如下:

4、 SHOW TABLE STATUS[like 'A']

其STATE为 Waiting for table metadata lock

显然MDL_SHARED_READ(SR) 和MDL_SHARED_HIGH_PRIO(SH)是不兼容的还要停留。

2、DROP TABLE A

其STATE为 Waiting for table metadata lock

从他反应的状况意味着着他在最后杀掉了另2个 长期的未提交的事物有些有些他意味着着是状况2。有之前 整个CREATE TABLE A AS SELECT B说说意味着着B表上有些数据库被上了锁而只有获取,意味着着整个说说所处sending data状况下。

今天另2个 大伙遇到数据库遇到另2个 严重的故障,故障环境如下:

建议先阅读我的如下文章来学习MDL LOCK:

http://blog.itpub.net/7728585/viewspace-21410093/

1、 对db下每个表上MDL (SH) lock如下(调用MDL_context::acquire_lock 这里给出堵塞从前的信息)

都可不可以 看完USE DB随便说说 也意味着着MDL_SHARED_HIGH_PRIO(SH) 所处了堵塞。





故障信息提取

有之前 MDL_SHARED_HIGH_PRIO(SH) 是另2个 优先级非常高的另2个 MDL LOCK类型表现如下:



还是回到上图,大伙都可不可以 归纳一下说说类型如下:

其被堵塞的条件除了被MDL_EXCLUSIVE(X)堵塞这麼 有些的意味着着。这麼 这如果 另2个 非常重要的突破口。

  • 由步骤1引起了CREATE TABLE A AS SELECT B的堵塞

意味着着RR模式下SELECT B必然对B表上满足的数据上锁,意味着着步骤1意味着着加锁有些有些触发停留,STATE为sending data。
  • 由步骤2引起了有些说说的堵塞

意味着着CRATE TABLE A AS SELECT B在A表建立完成以完会上MDL_EXCLUSIVE(X),这把锁会堵塞有些完整版的关于A表的说说,包括DESC/SHOW TABLE STATUS/USE DB(非-A) 这种 只上MDL_SHARED_HIGH_PRIO(SH)MDL LOCK 的说说。STATE统一为Waiting for table metadata lock。模拟测试

测试环境:

法律法律依据一:笔者在MDL LOCK源码加锁函数处加日志输出,意味着着要分析各种说说加MDL LOCK的类型还只有用这种 法律法律依据,意味着着MDL LOCK加锁往往一闪而过,performance_schema.metadata_locks 这麼 法律法律依据观察到。

都可不可以 看完随便说说 有MDL_SHARED_READ(SR)的所处,当前所处堵塞状况

本节关于MDL LOCK的验证使用下面五种法律法律依据:

在P_S中打开mdl监测法律法律依据如下:

这里比较遗憾在performance_schema.metadata_locks中并这麼 显示出MDL_EXCLUSIVE(X),而显示为MDL_SHARED(S) 有之前 大伙在我输出的日志中都可不可以 看完这里做了升级操作将MDL_SHARED(S) 升级为了MDL_EXCLUSIVE(X)。有之前 由前面的兼容性列表来看,只有MDL_EXCLUSIVE(X)会堵塞MDL_SHARED_HIGH_PRIO(SH)。有些有些大伙应该都都可不可以 确认这里随便说说 做了升级操作,有之前 SHOW TABLE STATUS[like 'A'] 是不不被堵塞的。



法律法律依据二:所处堵塞状况下使用5.7版本的performance_schema.metadata_locks观察。

我知道你大伙认为SELECT不不上锁,有之前 那是在innodb 层次,在MYSQL层会上MDL_SHARED_READ(SR) 如下:

要分挥发这种 案列随便说说 不太容易意味着着他是MYSQL层MDL LOCK和RR模式innodb row lock的另2个 综合案列,有之前 大伙要对schema.processlist的STATE比较敏感才行。

五种法律法律依据都能观察到MDL_SHARED_HIGH_PRIO(SH)的所处有之前 我模拟的是所处堵塞状况下的。

情急之下他杀掉了一大堆应用系统进程后发现还是只有恢复,最后杀掉了另2个 这麼 及时提交的事物才恢复正常。也仅仅留下了如下图的另2个 截图:

从前大伙就完美的模拟出线上的状况,意味着着大伙杀掉session1中的事物,自然就完整版解锁了,让大伙再来看一下performance_schema.metadata_locks中的输出:

步骤如下:

2、对每个表加入到table cache,有之前 打开表(调用open_table_from_share())

大伙都可不可以 看完如上的输出,有之前 还要注意LOCK_TYPE: SHARED它不意味着着堵塞LOCK_TYPE: SHARED_HIGH_PRIO(都可不可以 参考附录意味着着我从前写的MDL LOCK分析的文章)如上文分析这里实际上是做了升级操作升级为了MDL_EXCLUSIVE(X)。

一并大伙还还要注意在RR模式下SELECT B这种 帕累托图加锁法律法律依据和INSERT...SELECT是一致的参考不再赘述:

http://blog.itpub.net/7728585/viewspace-2146183/

这种 点很好分析意味着着A表上了X锁而DROP TABLE A必然上MDL_EXCLUSIVE(X)锁它当然和MDL_EXCLUSIVE(X)不兼容。如下:

”微信公众号

最后大伙看完的停留状况如下:

MDL LOCK TYPE

这是本案例中最重要的一环,SHOW TABLE STATUS[like 'A']果真被堵塞其STATE为Waiting for table metadata lock有之前 注意这里是table意味着着MDL LOCK类型分为有些有些。我在MDL介绍的那篇文章中提到了desc 另2个 表的以完会上MDL_SHARED_HIGH_PRIO(SH),其随便说说 SHOW TABLE STATUS的从前也会对本表上MDL_SHARED_HIGH_PRIO(SH)。

停留队列优先级矩阵

1、CREATE TABLE A AS SELECT B

其STATE为 sending data



原文发布时间为:2017-12-22本文作者:高鹏本文来自云栖社区合作协议伙伴“

兼容性矩阵

其兼容性如下:

”,了解相关信息都可不可以 关注“

意味着着使用mysql客户端不使用-A选项(意味着着 no-auto-rehash)在USE DB的从前要花费要做如下事情: