十年網(wǎng)站開發(fā)經(jīng)驗 + 多家企業(yè)客戶 + 靠譜的建站團隊
量身定制 + 運營維護+專業(yè)推廣+無憂售后,網(wǎng)站問題一站解決
查詢肯定會加讀鎖,對千萬量級別的場景,考慮主從多個數(shù)據(jù)庫架構(gòu)環(huán)境吧。
公司主營業(yè)務(wù):成都做網(wǎng)站、網(wǎng)站制作、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳,提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)公司是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴(yán)謹、自律”為核心的企業(yè)文化,感謝他們對我們的高要求,感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn),讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)公司推出鄞州免費做網(wǎng)站回饋大家。
在程序員的職業(yè)生涯中,總會遇到數(shù)據(jù)庫表被鎖的情況,前些天就又撞見一次。由于業(yè)務(wù)突發(fā)需求,各個部門都在批量操作、導(dǎo)出數(shù)據(jù),而數(shù)據(jù)庫又未做讀寫分離,結(jié)果就是:數(shù)據(jù)庫的某張表被鎖了!
用戶反饋系統(tǒng)部分功能無法使用,緊急排查,定位是數(shù)據(jù)庫表被鎖,然后進行緊急處理。這篇文章給大家講講遇到類似緊急狀況的排查及解決過程,建議點贊收藏,以備不時之需。
用戶反饋某功能頁面報502錯誤,于是第一時間看服務(wù)是否正常,數(shù)據(jù)庫是否正常。在控制臺看到數(shù)據(jù)庫CPU飆升,堆積大量未提交事務(wù),部分事務(wù)已經(jīng)阻塞了很長時間,基本定位是數(shù)據(jù)庫層出現(xiàn)問題了。
查看阻塞事務(wù)列表,發(fā)現(xiàn)其中有鎖表現(xiàn)象,本想利用控制臺直接結(jié)束掉阻塞的事務(wù),但控制臺賬號權(quán)限有限,于是通過客戶端登錄對應(yīng)賬號將鎖表事務(wù)kill掉,才避免了情況惡化。
下面就聊聊,如果當(dāng)突然面對類似的情況,我們該如何緊急響應(yīng)?
想象一個場景,當(dāng)然也是軟件工程師職業(yè)生涯中會遇到的一種場景:原本運行正常的程序,某一天突然數(shù)據(jù)庫的表被鎖了,業(yè)務(wù)無法正常運轉(zhuǎn),那么我們該如何快速定位是哪個事務(wù)鎖了表,如何結(jié)束對應(yīng)的事物?
首先最簡單粗暴的方式就是:重啟MySQL。對的,網(wǎng)管解決問題的神器——“重啟”。至于后果如何,你能不能跑了,要你自己三思而后行了!
重啟是可以解決表被鎖的問題的,但針對線上業(yè)務(wù)很顯然不太具有可行性。
下面來看看不用跑路的解決方案:
遇到數(shù)據(jù)庫阻塞問題,首先要查詢一下表是否在使用。
如果查詢結(jié)果為空,那么說明表沒在使用,說明不是鎖表的問題。
如果查詢結(jié)果不為空,比如出現(xiàn)如下結(jié)果:
則說明表(test)正在被使用,此時需要進一步排查。
查看數(shù)據(jù)庫當(dāng)前的進程,看看是否有慢SQL或被阻塞的線程。
執(zhí)行命令:
該命令只顯示當(dāng)前用戶正在運行的線程,當(dāng)然,如果是root用戶是能看到所有的。
在上述實踐中,阿里云控制臺之所以能夠查看到所有的線程,猜測應(yīng)該使用的就是root用戶,而筆者去kill的時候,無法kill掉,是因為登錄的用戶非root的數(shù)據(jù)庫賬號,無法操作另外一個用戶的線程。
如果情況緊急,此步驟可以跳過,主要用來查看核對:
如果情況緊急,此步驟可以跳過,主要用來查看核對:
看事務(wù)表INNODB_TRX中是否有正在鎖定的事務(wù)線程,看看ID是否在show processlist的sleep線程中。如果在,說明這個sleep的線程事務(wù)一直沒有commit或者rollback,而是卡住了,需要手動kill掉。
搜索的結(jié)果中,如果在事務(wù)表發(fā)現(xiàn)了很多任務(wù),最好都kill掉。
執(zhí)行kill命令:
對應(yīng)的線程都執(zhí)行完kill命令之后,后續(xù)事務(wù)便可正常處理。
針對緊急情況,通常也會直接操作第一、第二、第六步。
這里再補充一些MySQL鎖相關(guān)的知識點:數(shù)據(jù)庫鎖設(shè)計的初衷是處理并發(fā)問題,作為多用戶共享的資源,當(dāng)出現(xiàn)并發(fā)訪問的時候,數(shù)據(jù)庫需要合理地控制資源的訪問規(guī)則,而鎖就是用來實現(xiàn)這些訪問規(guī)則的重要數(shù)據(jù)結(jié)構(gòu)。
根據(jù)加鎖的范圍,MySQL里面的鎖大致可以分成全局鎖、表級鎖和行鎖三類。MySQL中表級別的鎖有兩種:一種是表鎖,一種是元數(shù)據(jù)鎖(metadata lock,MDL)。
表鎖是在Server層實現(xiàn)的,ALTER TABLE之類的語句會使用表鎖,忽略存儲引擎的鎖機制。表鎖通過lock tables… read/write來實現(xiàn),而對于InnoDB來說,一般會采用行級鎖。畢竟鎖住整張表影響范圍太大了。
另外一個表級鎖是MDL(metadata lock),用于并發(fā)情況下維護數(shù)據(jù)的一致性,保證讀寫的正確性,不需要顯式的使用,在訪問一張表時會被自動加上。
常見的一種鎖表場景就是有事務(wù)操作處于:Waiting for table metadata lock狀態(tài)。
MySQL在進行alter table等DDL操作時,有時會出現(xiàn)Waiting for table metadata lock的等待場景。
一旦alter table TableA的操作停滯在Waiting for table metadata lock狀態(tài),后續(xù)對該表的任何操作(包括讀)都無法進行,因為它們也會在Opening tables的階段進入到Waiting for table metadata lock的鎖等待隊列。如果核心表出現(xiàn)了鎖等待隊列,就會造成災(zāi)難性的后果。
通過show processlist可以看到表上有正在進行的操作(包括讀),此時alter table語句無法獲取到metadata 獨占鎖,會進行等待。
通過show processlist看不到表上有任何操作,但實際上存在有未提交的事務(wù),可以在information_schema.innodb_trx中查看到。在事務(wù)沒有完成之前,表上的鎖不會釋放,alter table同樣獲取不到metadata的獨占鎖。
處理方法:通過 select * from information_schema.innodb_trxG, 找到未提交事物的sid,然后kill掉,讓其回滾。
通過show processlist看不到表上有任何操作,在information_schema.innodb_trx中也沒有任何進行中的事務(wù)。很可能是因為在一個顯式的事務(wù)中,對表進行了一個失敗的操作(比如查詢了一個不存在的字段),這時事務(wù)沒有開始,但是失敗語句獲取到的鎖依然有效,沒有釋放。從performance_schema.events_statements_current表中可以查到失敗的語句。
處理方法:通過performance_schema.events_statements_current找到其sid,kill 掉該session,也可以kill掉DDL所在的session。
總之,alter table的語句是很危險的(核心是未提交事務(wù)或者長事務(wù)導(dǎo)致的),在操作之前要確認對要操作的表沒有任何進行中的操作、沒有未提交事務(wù)、也沒有顯式事務(wù)中的報錯語句。
如果有alter table的維護任務(wù),在無人監(jiān)管的時候運行,最好通過lock_wait_timeout設(shè)置好超時時間,避免長時間的metedata鎖等待。
關(guān)于MySQL的鎖表其實還有很多其他場景,我們在實踐的過程中盡量避免鎖表情況的發(fā)生,當(dāng)然這需要一定經(jīng)驗的支撐。但更重要的是,如果發(fā)現(xiàn)鎖表我們要能夠快速的響應(yīng),快速的解決問題,避免影響正常業(yè)務(wù),避免情況進一步惡化。所以,本文中的解決思路大家一定要收藏或記憶一下,做到有備無患,避免突然狀況下抓瞎。
行鎖的等待
在介紹如何解決行鎖等待問題前,先簡單介紹下這類問題產(chǎn)生的原因。產(chǎn)生原因簡述:當(dāng)多個事務(wù)同時去操作(增刪改)某一行數(shù)據(jù)的時候,MySQL 為了維護 ACID 特性,就會用鎖的形式來防止多個事務(wù)同時操作某一行數(shù)據(jù),避免數(shù)據(jù)不一致。只有分配到行鎖的事務(wù)才有權(quán)力操作該數(shù)據(jù)行,直到該事務(wù)結(jié)束,才釋放行鎖,而其他沒有分配到行鎖的事務(wù)就會產(chǎn)生行鎖等待。如果等待時間超過了配置值(也就是 innodb_lock_wait_timeout 參數(shù)的值,個人習(xí)慣配置成 5s,MySQL 官方默認為 50s),則會拋出行鎖等待超時錯誤。
如上圖所示,事務(wù) A 與事務(wù) B 同時會去 Insert 一條主鍵值為 1 的數(shù)據(jù),由于事務(wù) A 首先獲取了主鍵值為 1 的行鎖,導(dǎo)致事務(wù) B 因無法獲取行鎖而產(chǎn)生等待,等到事務(wù) A 提交后,事務(wù) B 才獲取該行鎖,完成提交。這里強調(diào)的是行鎖的概念,雖然事務(wù) B 重復(fù)插入了主鍵,但是在獲取行鎖之前,事務(wù)一直是處于行鎖等待的狀態(tài),只有獲取行鎖后,才會報主鍵沖突的錯誤。當(dāng)然這種 Insert 行鎖沖突的問題比較少見,只有在大量并發(fā)插入場景下才會出現(xiàn),項目上真正常見的是 updatedelete 之間行鎖等待,這里只是用于示例,原理都是相同的。
三、產(chǎn)生的原因根據(jù)我之前接觸到的此類問題,大致可以分為以下幾種原因
這個是屬于系統(tǒng)遺留問題,也就是一種系統(tǒng)的保護機制。就是為了避免出現(xiàn)這種在線修改系統(tǒng)的操作。
增加字段屬于系統(tǒng)的修改操作。盡量不要在線操作,因為可能出現(xiàn)。未知的漏洞。一定要。離線。修改完畢,然后經(jīng)過測試后。認為已經(jīng)沒有問題了。在。次日的凌晨發(fā)一個通知。停機維護。這樣才能保證系統(tǒng)的正常運轉(zhuǎn)。
如果在前期設(shè)置系統(tǒng)的時候就預(yù)留了。熱升級的空間。這樣才能達到在線操作的目的,而且系統(tǒng)的金融群總是一部分先升級。
很多情況下,你需要使用系統(tǒng)里邊的工具集。在線修改表格。原理其實非常的簡單,新建的和原表的表格結(jié)構(gòu)。要一模一樣。對這個表格進行修改,然后把結(jié)構(gòu)變更的日期。插入進去。而且還建議您盡量在業(yè)務(wù)的低縫隙進行修改。避免發(fā)生不可控的未知狀況。
使用說明:
1、如果是用 MySQL + Apache,使用的又是 FreeBSD 網(wǎng)絡(luò)操作系統(tǒng)的話,安裝時候你應(yīng)按注意到FreeBSD的版本問題,在FreeBSD 的 3.0 以下版本來說,MySQL Source 內(nèi)含的 MIT-pthread 運行是正常的,但在這版本以上,你必須使用 native threads。
2、如果在 COMPILE 過程中出了問題,請先檢查你的 gcc版本是否在 2.81 版本以上,gmake 版本是否在3.75以上。
3、如果不是版本的問題,那可能是你的內(nèi)存不足,請使用configure--with-low-memory 來加入。
4、如果要重新做你的configure,那么你可以鍵入rm config.cache和make clean來清除記錄。
5、把 MySQL 安裝在 /usr/local 目錄下,這是缺省值,您也可以按照你的需要設(shè)定你所安裝的目錄。