本篇文章給大家?guī)?lái)了關(guān)于mysql的相關(guān)知識(shí),其中主要介紹了關(guān)于全局鎖的相關(guān)問(wèn)題,全局鎖就是對(duì)整個(gè)數(shù)據(jù)庫(kù)加鎖。當(dāng)我們對(duì)數(shù)據(jù)庫(kù)加了讀鎖之后,其他任何的請(qǐng)求都不能對(duì)數(shù)據(jù)庫(kù)加寫(xiě)鎖了,下面一起來(lái)看一下,希望對(duì)大家有幫助。
推薦學(xué)習(xí):mysql視頻教程
數(shù)據(jù)庫(kù)設(shè)計(jì)的初衷是處理并發(fā)問(wèn)題的,作為多用戶(hù)共享的資源,當(dāng)出現(xiàn)并發(fā)訪(fǎng)問(wèn)時(shí),數(shù)據(jù)庫(kù)需要合理地控制資源的訪(fǎng)問(wèn)規(guī)則。而鎖就是用來(lái)實(shí)現(xiàn)這個(gè)訪(fǎng)問(wèn)規(guī)則的重要數(shù)據(jù)結(jié)構(gòu)。
我們先來(lái)貼一個(gè)鎖的大概分類(lèi)的圖
根據(jù)加鎖的范圍,MySQL 里面的鎖大致可以分為全局鎖、表鎖、行鎖。我們主要先來(lái)學(xué)習(xí)這幾種鎖,這篇我們學(xué)習(xí)全局鎖。
全局鎖
全局鎖就是對(duì)整個(gè)數(shù)據(jù)庫(kù)加鎖。當(dāng)我們對(duì)數(shù)據(jù)庫(kù)加了讀鎖之后,其他任何的請(qǐng)求都不能對(duì)數(shù)據(jù)庫(kù)加寫(xiě)鎖了,當(dāng)我們對(duì)數(shù)據(jù)庫(kù)加了寫(xiě)鎖之后,后續(xù)其他任何的請(qǐng)求都不能對(duì)數(shù)據(jù)庫(kù)加讀鎖和寫(xiě)鎖了。
FTWRL
MySQL 提供了一個(gè)加全局讀鎖的方法,F(xiàn)lush tables with read lock (FTWRL)。當(dāng)我們需要讓整個(gè)庫(kù)處于只讀狀態(tài)時(shí),可以使用這個(gè)命令,之后其他線(xiàn)程的以下語(yǔ)句會(huì)被阻塞:數(shù)據(jù)更新語(yǔ)句(增刪改)、數(shù)據(jù)定義語(yǔ)句(包括建表、修改表結(jié)構(gòu)等)和更新類(lèi)事務(wù)的提交語(yǔ)句。
全局鎖的使用場(chǎng)景
全局鎖的使用場(chǎng)景:做全庫(kù)的邏輯備份。邏輯備份也就是把整個(gè)庫(kù)的每個(gè)表都 select 出來(lái)存成文本。也就是全局鎖只有在進(jìn)行主從備份數(shù)據(jù)或者導(dǎo)入導(dǎo)出數(shù)據(jù)的時(shí)候才會(huì)使用到。
那么為什么需要全局鎖呢?
因?yàn)槲覀冊(cè)谧鰯?shù)據(jù)備份或者導(dǎo)入導(dǎo)出數(shù)據(jù)的時(shí)候,如果在這個(gè)期間還可以同時(shí)進(jìn)行數(shù)據(jù)的增刪改,那么就會(huì)出現(xiàn)數(shù)據(jù)不一致的問(wèn)題。
以前有一種做法是通過(guò)上面提到的 FTWRL 確保在備份的時(shí)候不會(huì)有其他線(xiàn)程對(duì)數(shù)據(jù)庫(kù)做更新,注意:這里備份過(guò)程中整個(gè)庫(kù)都是完全處于只讀狀態(tài)。
因?yàn)槿宙i是面向這個(gè)數(shù)據(jù)庫(kù)的,所以加全局鎖聽(tīng)起來(lái)很危險(xiǎn):
- 如果我們?cè)谥鲙?kù)上備份,在備份期間都不能執(zhí)行更新,也就是基本上全部業(yè)務(wù)暫停。
- 如果我們?cè)趶膸?kù)上備份,在備份期間主庫(kù)同步過(guò)來(lái)的 binlog 從庫(kù)都不能執(zhí)行,也就是會(huì)導(dǎo)致主從延遲,數(shù)據(jù)不一致。
如何避免加鎖
既然加全局鎖影響這么大,我們能不能避免加鎖呢?
通過(guò)上面的介紹,我們知道加鎖是為了解決數(shù)據(jù)不一致問(wèn)題。那么是不是只要我們能解決數(shù)據(jù)不一致的問(wèn)題,就可以不用加全局鎖了。有這樣一個(gè)思路:如果我們?cè)陂_(kāi)始進(jìn)行數(shù)據(jù)備份的時(shí)候,記錄一個(gè)操作日志,備份過(guò)程中不加鎖允許對(duì)數(shù)據(jù)庫(kù)的增刪改查,而在備份過(guò)程中,增刪改查的操作記錄都記到一個(gè)日志文件里,等我們備份完成后,再把這段時(shí)間日志文件里的操作都執(zhí)行一遍。這樣就能保證備份前后數(shù)據(jù)的一致性了。
總結(jié),不加鎖的話(huà),備份得到數(shù)據(jù)和主數(shù)據(jù)不是一個(gè)邏輯時(shí)間點(diǎn),這個(gè)視圖是邏輯不一致的。如果保證邏輯時(shí)間點(diǎn)一致即邏輯視圖一致就能保證數(shù)據(jù)一致,由此我們就想到了我們之前學(xué)過(guò)的事務(wù)隔離級(jí)別,可重復(fù)復(fù)讀的隔離級(jí)別下開(kāi)啟一個(gè)事務(wù)就是一個(gè)一致性視圖。
在 MySQL 的默認(rèn)引擎 InnoDB 里有一個(gè)機(jī)制可以保證數(shù)據(jù)一致性。InnoDB 引擎中有數(shù)據(jù)快照版本的功能,這個(gè)功能叫 MVCC,因?yàn)?MVCC 保留了歷史版本的快照,每個(gè)快照都對(duì)應(yīng)一個(gè)事務(wù)版本號(hào),而在我們備份數(shù)據(jù)的時(shí)候會(huì)申請(qǐng)一個(gè)事務(wù)版本號(hào),在讀取數(shù)據(jù)的時(shí)候,只需要讀取比自己事務(wù)版本號(hào)小的數(shù)據(jù)即可。
–single-transaction 命令加鎖
官方自帶的邏輯備份工具是 mysqldump。當(dāng) mysqldump 使用參數(shù) –single-transaction 的時(shí)候,導(dǎo)數(shù)據(jù)之前就會(huì)啟動(dòng)一個(gè)事務(wù),來(lái)確保拿到一致性視圖。而由于 MVCC 的支持,這個(gè)過(guò)程中數(shù)據(jù)是可以正常更新的。
–single-transaction 參數(shù)的作用,設(shè)置事務(wù)的隔離級(jí)別為可重復(fù)讀,即 REPEATABLE READ,這樣能保證在一個(gè)事務(wù)中所有相同的查詢(xún)讀取到同樣的數(shù)據(jù),也就大概保證了在 dump 期間,如果其他 InnoDB 引擎的線(xiàn)程修改了表的數(shù)據(jù)并提交,對(duì)該 dump 線(xiàn)程的數(shù)據(jù)并無(wú)影響。
并且設(shè)置 WITH CONSISTENT SNAPSHOT 為快照級(jí)別。設(shè)想一下,如果只是可重復(fù)讀,那么在事務(wù)開(kāi)始時(shí)還沒(méi) dump 數(shù)據(jù)時(shí),這時(shí)其他線(xiàn)程修改并提交了數(shù)據(jù),那么這時(shí)第一次查詢(xún)得到的結(jié)果是其他線(xiàn)程提交后的結(jié)果,而 WITH CONSISTENT SNAPSHOT 能夠保證在事務(wù)開(kāi)啟的時(shí)候,第一次查詢(xún)的結(jié)果就是事務(wù)開(kāi)始時(shí)的數(shù)據(jù) A,即使這時(shí)其他線(xiàn)程將其數(shù)據(jù)修改為 B,查的結(jié)果依然是 A。
single-transaction方法只適用于所有的表使用事務(wù)引擎的庫(kù)。在 mysqldump 過(guò)程中,加了–single-transaction 就能保證 InnoDB 的數(shù)據(jù)是完全一致的,對(duì)于MyISAM這種不支持事務(wù)的引擎,如果備份過(guò)程中有更新,總是只能取到最新的數(shù)據(jù),那么就破壞了備份的一致性。這時(shí)候就還是需要全局鎖的,所以我們就還是需要使用 FTWRL 命令的。
只讀設(shè)置
我們可能還會(huì)有這樣一個(gè)疑問(wèn),既然要全庫(kù)只讀,我們?yōu)槭裁床贿m用 set global readonly = true 的方式呢?
確實(shí) readonly 方式也可以讓全庫(kù)進(jìn)入只讀狀態(tài),但還是會(huì)建議用 FTWRL 方式,主要有兩個(gè)原因:
- 在有些系統(tǒng),readonly 的值會(huì)被用來(lái)做其他邏輯,比如用來(lái)判斷一個(gè)庫(kù)是主庫(kù)還是備庫(kù)。因此,修改global變量的方式影響面更大。
- 在異常處理機(jī)制上有差異。如果執(zhí)行 FTWRL 命令之后由于客戶(hù)端發(fā)生異常斷開(kāi),那么 MySQL 會(huì)自動(dòng)釋放這個(gè)全局鎖,整個(gè)庫(kù)回到可以正常更新的狀態(tài)。
而將整個(gè)庫(kù)設(shè)置為 readonly 之后,如果客戶(hù)端發(fā)生異常,則數(shù)據(jù)庫(kù)就會(huì)一直保持 readonly 狀態(tài),這樣會(huì)導(dǎo)致整個(gè)庫(kù)長(zhǎng)時(shí)間處于不可寫(xiě)狀態(tài),風(fēng)險(xiǎn)較高。
推薦學(xué)習(xí):mysql視頻教程