1. 程式人生 > >【MySQL經典案例分析】 Waiting for table metadata lock

【MySQL經典案例分析】 Waiting for table metadata lock

排查 同時 導致 大量 並發 技術幹貨 mysql模塊 lee exist

本文由雲+社區發表

一、 問題是這樣來的

? 2018年某個周末,接到連續數據庫的告警,告警信息如下:

技術分享圖片

二、 苦逼的探索過程

1、總體的思路

看到too many connection的報錯信息,基本上可以把問題定位在:

(1)機器負載飆升,導致SQL執行效率下降,導致連接推積

(2)業務訪問量突增(或者有SQL註入現象),導致連接數打滿

(3)出現“死鎖”或者鎖競爭嚴重,導致大量SQL堆積

2、排查過程

(1)機器的各項性能指標都顯示正常, 沒有出現高負載現象,暫時先排除了這種原因

(2)查看監控信息,發現在連接數打滿的時間點前並沒有訪問量突增的趨勢,同時通過檢查告警信息並沒有發現有註入工單

技術分享圖片

(3)最後上到服務器上查看下SQL的執行情況

①查看show full processlist;

技術分享圖片

? 大量的請求都是在“Waiting for table metadata lock”,可以分成三類請求:

  • Select請求
  • Rename請求
  • Sleep請求

②分析Waiting for table metadata lock

? 一般來說常見的“Waiting for table metadata lock”會出現在DDL操作或者是有未提交的事務上,從information_schema.processlist表中,沒有發現有DDL操作,而能夠產生MDL鎖的操作也只剩下rename,但是根據SQL執行的狀態,rename操作也是在等待MDL鎖,所以rename操作應該是被阻塞的操作,而不是產生MDL鎖的操作。

? 接著我們來查看下死鎖和事務的相關指標:

  • show engine innodb status;中沒有任何死鎖的信息
  • information_schema.innodb_trx 、information_schema.innodb_locks 、 information_schema.innodb_lock_waits 的也沒有任何形式的鎖信息。

? 現在基本又排除了顯示的死鎖問題,那是從show full processlist中也抓不出任何請求,這裏就比較疑惑了,當看了下表的結構式,發現這個表是myisam引擎的,所以上面的兩種統計信息裏面沒有任何值就可以解釋了。

技術分享圖片

? 那麽其實問題就集中在有未結束的事務上了,這裏其實有一個誤區,當時跟開發溝通存在未關閉的事務時,開發一直認為不可能,因為myisam表是不支持事務的,只有innodb支持事務。但是對於MDL鎖來說,5.5之後引入MDL事務級別的鎖不論對myisam還是innodb都是生效的。

③查看未提交的事務

? 之後查看了下系統的事務自動提交的變量,autocommit的值是ON,那說明如果是事務未提交的話只可能是業務主動的開啟一個事務,而沒有commit。

技術分享圖片

? 為了驗證這個猜想,打開了general log,在log中果然發現,業務在開啟事務後,把autocommit的值設為0了,導致必須要顯示的commit才能提交事務。

技術分享圖片

技術分享圖片

? 這時候我們反過頭來看一下host為10.49.84.70的連接請求,由於select的執行速度很快,而且訪問並不頻繁,所以在抽樣的show processlist中,狀態值大部分時間是“Sleep”,給問題的定位帶來了一些迷惑性的幹擾。接著我們kill掉了這個進程,果然推積的請求瞬間就執行完成了,也之間印證了剛剛上述推論。

2、問題解決

? 在與開發同學溝通過程中,開發同學說庫中是myisam表所以不會主動開啟事務,在代碼裏也沒有設置autocommit=0的代碼,那麽根本原因在哪?

? 當我們定位到這臺服務器上的請求都是來自python的定時腳本,使用python 操作mysql的時候,使用了其pymysql模塊,但是在進行插入操作的時候,必須使用受到提交事務。Python的pymysql模塊默認是會設置autocommit=0的。

技術分享圖片

? 讓我們來對比一下其他同樣使用python訪問的正常連接請求,再斷開前都會手動的commit。

技術分享圖片

? 找到原因後有思考了下,是不是可以在建連後就設置autocommit=1呢?這樣對於之後新變更的SQL就不要再考慮到手動commit的事情了,可以通過在初始化連接池的時候,對每一個連接進行設置,即

技術分享圖片

三、 延伸的一些思考

1、metadata lock

(1)MDL簡述

? 為了在並發環境下維護表元數據的數據一致性,在表上有活動事務(顯式或隱式)的時候,不可以對元數據進行寫入操作。因此從MySQL5.5版本開始引入了MDL鎖(metadata lock),來保護表的元數據信息,用於解決或者保證DDL操作與DML操作之間的一致性。

? 對於引入MDL,其主要解決了2個問題,一個是事務隔離問題,比如在可重復隔離級別下,會話A在2次查詢期間,會話B對表結構做了修改,兩次查詢結果就會不一致,無法滿足可重復讀的要求;另外一個是數據復制的問題,比如會話A執行了多條更新語句期間,另外一個會話B做了表結構變更並且先提交,就會導致slave在重做時,先重做alter,再重做update時就會出現復制錯誤的現象。所以在對表進行上述操作時,如果表上有活動事務(未提交或回滾),請求寫入的會話會等待在Metadata lock wait 。

? 支持事務的InnoDB引擎表和不支持事務的MyISAM引擎表,都會出現Metadata Lock Wait等待現象。一旦出現Metadata Lock Wait等待現象,後續所有對該表的訪問都會阻塞在該等待上,導致連接堆積,業務受影響。

(2)常見MDL鎖場景

①當前有執行DML操作時執行DDL操作

② 當前有對表的長時間查詢或使用mysqldump/mysqlpump時,使用alter會被堵住

③ 顯示或者隱式開啟事務後未提交或回滾,比如查詢完成後未提交或者回滾,DDL會被堵住

④ 表上有失敗的查詢事務,比如查詢不存在的列,語句失敗返回,但是事務沒有提交,此時DDL仍然會被堵住

2、myisam、innodb對事務的支持

? Myisam是不支持事務的,innodb是支持事務的,這個概念其實沒有任何問題,但是這裏只的都是對於數據的事務性操作的支持,通過如下簡單的實驗可以很清楚的理解(關於事務的相關概念和解釋就不再贅述了,只是想區別一下mysiam不支持事務,但是主動開始事務中對Myisam的操作仍然會產生MDL鎖):

? 在隔離級別為RC的情況下:

(1)myisam表

① CREATE TABLE tb2 (a int(11) DEFAULT NULL ) ENGINE=MyISAM;

② Session 1:

? mysql> begin ;

? mysql> insert into tb2(a) value(1);

? (在session2的update之後)

? mysql> select * from tb2;

? +--------+

? | a |

? +--------+

? | 3 |

? +--------+

Session 2:

? mysql> select * from tb2;

? +---------+

? | a |

? +---------+

? | 1 |

? +---------+

? mysql> update tb2 set a=3 where a=1;

? mysql> select * from tb2;

? +--------+

? | a |

? +--------+

? | 3 |

? +--------+

? mysql> alter table tb2 add b int(11);

... hangs ...

(2)innodb表

①CREATE TABLE tb3 (a int(11) DEFAULT NULL ) ENGINE=INNODB;

② Session 1:

? mysql> begin ;

? mysql> insert into tb3(a) value(1);

? Session 2:

? mysql> select * from tb3;

? Empty set (0.00 sec)

3、myisam表的另一個BUG

(1)場景

① CREATE TABLE tb2 (a int(11) DEFAULT NULL ) ENGINE=MyISAM;

② Session 1:

? mysql> begin ;

? mysql> select * from tb2;

? Session 2:

? mysql> create table if not exists tb2(a int);

? ... hangs ...

③查看show processlist

? Session 1:Sleep

? Session 2:Waiting for table metadata lock

(2)解決方式

①session 1上commit或者rollback

②另外再開一個session3 ,kill掉可疑連接

此文已由作者授權騰訊雲+社區發布

搜索關註公眾號「雲加社區」,第一時間獲取技術幹貨,關註後回復1024 送你一份技術課程大禮包!

【MySQL經典案例分析】 Waiting for table metadata lock