MySQL Online DDL導(dǎo)致全局鎖表案例分析

我這邊遇到了什么問題?

線上給某個表執(zhí)行新增索引SQL, 然后整個數(shù)據(jù)CPU打到100%, 連接數(shù)暴增到極限, 最后導(dǎo)致所有訪問數(shù)據(jù)庫的應(yīng)用都奔潰.

SQL如下:

ALTER TABLE `book`

ADD INDEX `idx_sub_title` (`sub_title` ASC);

能看到什么?

'10063293', 'root', '10.0.0.1:35252', 'novel', 'Query', '50', 'Waiting for table metadata lock',

'ALTER TABLE `lemon_novel`.`book` \nADD INDEX `idx_sub_title` (`sub_title` ASC)'

'10094494', 'root', '172.16.2.112:42808', 'novel', 'Query', '31', 'Waiting for table metadata lock', 'SELECT \n

book_trend.book_id AS book_id,

很奇怪, 這兩邊都在等"Waiting for table metadata lock"

反手查一下"Waiting for table metadata lock"是什么

初步的一些結(jié)論

看下來下面的一些結(jié)論:MySQL 5.6以后的版本，支持在線DDL，新增index/刪除index之類的可以直接InPlace操作,不需要rebuild整張表，理論上效果是很快的，詳細資料見Online DDL Operations

DDL add index 操作會lock table metadata，此操作是導(dǎo)致我們服務(wù)不可用的原因

有懷疑過lock tabel matadata和MySQL autocommit有關(guān)，但是實踐下來兩者看起來沒有關(guān)聯(lián)。

后來在阿里云上面還看到過他們特定寫過類似的答疑.

阿里云建議主要是這樣操作.這里需要找到的是一直在占用該表的會話，而不是正在等待MDL鎖解除的會話，注意區(qū)分。可以根據(jù)State列的狀態(tài)和Info列的命令內(nèi)容來進行分析判斷。

您也可以用如下命令查詢長時間未完成的事務(wù)，如果導(dǎo)致阻塞的語句的用戶與當前用戶不同，請使用導(dǎo)致阻塞的語句的用戶登錄來終止會話。

select concat('kill ',i.trx_mysql_thread_id,';') from information_schema.innodb_trx i,

(select

id, time

from

information_schema.processlist

where

time = (select

max(time)

from

information_schema.processlist

where

state = 'Waiting for table metadata lock'

and substring(info, 1, 5) in ('alter' , 'optim', 'repai', 'lock ', 'drop ', 'creat'))) p

where timestampdiff(second, i.trx_started, now()) > p.time

and i.trx_mysql_thread_id not in (connection_id(),p.id);

然而在我的場景, 上面的SQL并沒有任何的進程輸出.

陷入僵局的...

不過上面給了一些思路, 現(xiàn)在我們主要是因為有東西占用著 table metadata lock, 導(dǎo)致當前所有的東西都沒有執(zhí)行.

showfull processlist;

看一眼沒什么卵用, 處理那兩個奇怪的wait lock, 其他的都挺正常的.

那么, 看下現(xiàn)在誰占用著鎖? 怎么看呢?

select*from information_schema.innodb_trx;

神奇了, 真有兩個東西在占用鎖.

那kill 了他們看看.

額, 解決了.

最終結(jié)論

某個奇怪的程序開了查詢或者奇怪的操作,lock了 table metadata,

之后連接一直都沒有被釋放, 導(dǎo)致以上各種問題.

現(xiàn)在的問題來了, 究竟是哪個程序或者哪個代碼導(dǎo)致的呢?

抱歉, 我現(xiàn)在也還不知道...

理論上可以查,

但是上次去查的時候發(fā)現(xiàn)數(shù)據(jù)庫顯示的host對應(yīng)機器的端口早就沒東西了,

死無對證ing.

最后建議online DDL前,最好確認一下當前數(shù)據(jù)庫有沒有類似table metadata lock存在

最好的方案還是主從切換來搞

全文完.

總結(jié)

以上是生活随笔為你收集整理的mysql ddl 锁_MySQL Online DDL导致全局锁表案例分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。