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

  • 时间:
  • 浏览:1
  • 来源:神彩大发幸运飞艇_彩神大发幸运飞艇官方

这里比较遗憾在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'] 是不需要被堵塞的。



其被堵塞的条件除了被MDL_EXCLUSIVE(X)堵塞没法一些的不可能 。没法这什么都有曾经非常重要的突破口。

信息分析

其兼容性如下:

GITD关闭RR隔离级别

使用脚本:

没法这俩请况就和SHOW TABLE STATUS[like 'A']被堵塞的请况一模一样了,也是不可能 MDL 锁不兼容造成的。

可否看一遍实在有MDL_SHARED_READ(SR)的位于,当前位于堵塞请况

跟我说愿意们认为SELECT不需要上锁,有日后那是在innodb 层次,在MYSQL层会上MDL_SHARED_READ(SR) 如下:

要分挥发掉这俩案列实在不太容易不可能 他是MYSQL层MDL LOCK和RR模式innodb row lock的曾经综合案列,不愿意们要对schema.processlist的STATE比较敏感才行。

  • 由步骤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_SHARED_HIGH_PRIO(SH)的位于有日后我模拟的是位于堵塞请况下的。

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

4、 SHOW TABLE STATUS[like 'A']

其STATE为 Waiting for table metadata lock

还是回到上图,愿意们可否归纳一下一段话类型如下:

今天曾经愿意们遇到数据库遇到曾经严重的故障,故障环境如下:

兼容性矩阵

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

曾经愿意们就完美的模拟出线上的请况,不可能 愿意们杀掉session1中的事物,自然就全版解锁了,让愿意们再来看一下performance_schema.metadata_locks中的输出:

本节关于MDL LOCK的验证使用下面本身土方式:

不可能 使用mysql客户端不使用-A选项(不可能 no-auto-rehash)在USE DB的日后 大概要做如下事情:

从他反应的请况不可能 他在最后杀掉了曾经长期的未提交的事物什么都有他不可能 是请况2。有日后整个CREATE TABLE A AS SELECT B一段话不可能 B表上一些数据库被上了锁而没法获取,原困整个一段话位于sending data请况下。

3、SELECT * FROM A

其STATE为 Waiting for table metadata lock

这俩些也是我日后 我不在 乎 的,也是本案列中花时间最多的地方,前文不可能 分析过要让SHOW TABLE STATUS[like 'A']这俩只会上MDL_SHARED_HIGH_PRIO(SH) MDL LOCK的一段话堵塞在MDL LOCK上没法本身不可能 那什么都有A表上了MDL_EXCLUSIVE(X)。



”微信公众号

同去愿意们还须要注意在RR模式下SELECT B这俩次责加锁土方式和INSERT...SELECT是一致的参考不再赘述:

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

”,了解相关信息可否关注“

没法我日后 刚结束了了怀疑这俩DDL一段话在一段话日后 结束了了日后 会对A表上MDL_EXCLUSIVE(X) ,有日后进行实际测试不在 所料实在是曾经的如下:

2、DROP TABLE A

其STATE为 Waiting for table metadata lock

有了前面的分析没法愿意们可否梳理这俩故障位于的原困如下:

土方式一:笔者在MDL LOCK源码加锁函数处加日志输出,不可能 要分析各种一段话加MDL LOCK的类型还没法用这俩土方式,不可能 MDL LOCK加锁往往一闪而过,performance_schema.metadata_locks 没法土方式观察到。

情急之下他杀掉了一大堆应用程序后发现还是没法恢复,最后杀掉了曾经没法及时提交的事物才恢复正常。也仅仅留下了如下图的曾经截图:

最后愿意们看一遍的等待英文请况如下:

这是本案例中最重要的一环,SHOW TABLE STATUS[like 'A']青春恋爱物语被堵塞其STATE为Waiting for table metadata lock有日后注意这里是table不可能 MDL LOCK类型分为什么都有。我在MDL介绍的那篇文章中提到了desc 曾经表的日后 会上MDL_SHARED_HIGH_PRIO(SH),实在在SHOW TABLE STATUS的日后 也会对本表上MDL_SHARED_HIGH_PRIO(SH)。

这俩些很好分析不可能 A表上了X锁而DROP TABLE A必然上MDL_EXCLUSIVE(X)锁它当然和MDL_EXCLUSIVE(X)不兼容。如下:

可否看一遍USE DB实在什么都有可能 MDL_SHARED_HIGH_PRIO(SH) 位于了堵塞。

表现如下:

愿意们可否看一遍如上的输出,有日后须要注意LOCK_TYPE: SHARED它不需要可能 堵塞LOCK_TYPE: SHARED_HIGH_PRIO(可否参考附录不可能 我日后 写的MDL LOCK分析的文章)如上文分析这里实际上是做了升级操作升级为了MDL_EXCLUSIVE(X)。





关于sending data这俩请况实在可否代表什么都有含义,从我现有的对的了解,这是MYSQL上层对SELECT类型一段话的相似 一段话在INNODB层和MYSQL层进行数据交互的日后 曾经统称,什么都有跳出它的不可能 中含:

MDL LOCK TYPE

故障信息提取

土方式二:位于堵塞请况下使用5.7版本的performance_schema.metadata_locks观察。

步骤如下:

等待英文队列优先级矩阵



其中EXCLUSIVE什么都有愿意们说的MDL_EXCLUSIVE(X)它实在位于当前位于堵塞

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

http://blog.itpub.net/7728585/viewspace-21460 93/

在P_S中打开mdl监测土方式如下:

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

遇到故障,愿意们往往想的是如保补救这俩故障,而与否从故障的根本去思考跳出这俩故障的原困?曾经的结果,没法使愿意们得到了鱼,遗弃了渔。今天,愿意们就来分享曾经由USE DB堵塞故障引发的思考案例。

有日后MDL_SHARED_HIGH_PRIO(SH) 是曾经优先级非常高的曾经MDL LOCK类型表现如下:

1、CREATE TABLE A AS SELECT B

其STATE为 sending data

显然MDL_SHARED_READ(SR) 和MDL_SHARED_HIGH_PRIO(SH)是不兼容的须要等待英文。