[背景簡介]

MySQL是一種開放源代碼的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)(RDBMS)，因為其速度、可靠性和適應(yīng)性而備受關(guān)注。大多數(shù)人都認(rèn)為在不需要事務(wù)化處理的情況下，MySQL是管理內(nèi)容最好的選擇。mysql雖然功能未必很強(qiáng)大，但因為它的開源、廣泛傳播，導(dǎo)致很多人都了解到這個數(shù)據(jù)庫。故障基本都能通過社區(qū)和官方文檔獲取解決方案，在應(yīng)用范圍上也是很廣的，互聯(lián)網(wǎng)公司基本都有使用mysql。本章主要針對mysql5.7.25的鎖表故障進(jìn)行分析處理。

[分析過程]

1、首先接到業(yè)務(wù)反饋數(shù)據(jù)庫完全無法寫入數(shù)據(jù)了，后查看數(shù)據(jù)庫監(jiān)控發(fā)現(xiàn)指標(biāo)正常；

2、登陸數(shù)據(jù)庫主機(jī)核實主機(jī)資源正常：

3、通過showprocesslist查看當(dāng)前連接，發(fā)現(xiàn)300左右的連接基本全是waitingfor global read lock和少部分waitingfor stored function metadata lock以及FLUSHTABLES WITH READ LOCK，如下所示

4、通過showOPEN TABLES where In_use > 0查看當(dāng)前被鎖表xx_test，

5、通過查看當(dāng)前事務(wù)發(fā)現(xiàn)只有兩個事務(wù)；

6、通過查看當(dāng)前正在鎖事務(wù)和等待鎖事務(wù)，發(fā)現(xiàn)并沒有記錄有正在鎖事務(wù)和等待鎖事務(wù)

7、通過查看當(dāng)前事務(wù)確認(rèn)到目前只有兩個事務(wù)在運行，其它都是都在等待，且無等待鎖表及正在鎖表。

8、發(fā)現(xiàn)備份賬號FLUSHTABLES WITH READ LOCK關(guān)閉所有打開的表并使用全局讀鎖鎖定所有數(shù)據(jù)庫的所有表，所以業(yè)務(wù)查詢沒有問題。

9、猜想應(yīng)該是因為xx_test的鎖表阻塞了FLUSHTABLES WITH READ LOCK執(zhí)行，導(dǎo)致整個數(shù)據(jù)庫完全無法修改。

[驗證過程]

首先通過processlist輸出看到鎖表xx_test連接有3個等待該表的鎖，其它并沒有該表請求連接，先將這三個等待的select連接kill。

然后將當(dāng)前正在執(zhí)行的兩個事務(wù)kill。

觀察數(shù)據(jù)庫發(fā)現(xiàn)FLUSH TABLES WITH READ LOCK結(jié)束，其它等待事務(wù)都開始執(zhí)行，數(shù)據(jù)庫恢復(fù)正常。

[總結(jié)]

數(shù)據(jù)庫觸發(fā)FLUSHTABLES WITH READLOCK應(yīng)該是有業(yè)務(wù)方在備份，單純的表被鎖了一般情況下也只會影響鎖表的寫，但是在鎖表情況的備份觸發(fā)FLUSHTABLES WITH READ LOCK，就可能導(dǎo)致整個庫變成只讀，建議備份工作都放在晚上閑時。

總結(jié)

以上是生活随笔為你收集整理的mysql锁表查询_Mysql数据库锁情况下开启备份导致数据库无法访问处理分享的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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