您好,登錄后才能下訂單哦!
這篇文章主要講解了“MySQL怎么保證備份數(shù)據(jù)的一致性”,文中的講解內(nèi)容簡單清晰,易于學(xué)習(xí)與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“MySQL怎么保證備份數(shù)據(jù)的一致性”吧!
為了數(shù)據(jù)安全,數(shù)據(jù)庫需要定期備份,這個大家都懂,然而數(shù)據(jù)庫備份的時候,最怕寫操作,因為這個最容易導(dǎo)致數(shù)據(jù)的不一致,松哥舉一個簡單的例子大家來看下:
假設(shè)在數(shù)據(jù)庫備份期間,有用戶下單了,那么可能會出現(xiàn)如下問題:
庫存表扣庫存。
備份庫存表。
備份訂單表數(shù)據(jù)。
訂單表添加訂單。
用戶表扣除賬戶余額。
備份用戶表。
如果按照上面這樣的邏輯執(zhí)行,備份文件中的訂單表就少了一條記錄。將來如果使用這個備份文件恢復(fù)數(shù)據(jù)的話,就少了一條記錄,造成數(shù)據(jù)不一致。
為了解決這個問題,MySQL 中提供了很多方案,我們來逐一進(jìn)行講解并分析其優(yōu)劣。
要解決這個問題,我們最容易想到的辦法就是在數(shù)據(jù)庫備份期間設(shè)置數(shù)據(jù)庫只讀,不能寫,這樣就不用擔(dān)心數(shù)據(jù)不一致了,設(shè)置全庫只讀的辦法也很簡單,首先我們執(zhí)行如下 SQL 先看看對應(yīng)變量的值:
show variables like 'read_only';
可以看到,默認(rèn)情況下,read_only
是 OFF,即關(guān)閉狀態(tài),我們先把它改為 ON,執(zhí)行如下 SQL:
set global read_only=1;
1 表示 ON,0 表示 OFF,執(zhí)行結(jié)果如下:
這個 read_only
對 super 用戶無效,所以設(shè)置完成后,接下來我們退出來這個會話,然后創(chuàng)建一個不包含 super 權(quán)限的用戶,用新用戶登錄,登錄成功之后,執(zhí)行一個插入 SQL,結(jié)果如下:
可以看到,這個錯誤信息中說,現(xiàn)在的 MySQL 是只讀的(只能查詢),不能執(zhí)行當(dāng)前 SQL。
加了只讀屬性,就不用擔(dān)心備份的時候發(fā)生數(shù)據(jù)不一致的問題了。
但是 read_only
我們通常用來標(biāo)識一個 MySQL 實例是主庫還是從庫:
read_only=0,表示該實例為主庫。數(shù)據(jù)庫管理員 DBA 可能每隔一段時間就會對該實例寫入一些業(yè)務(wù)無關(guān)的數(shù)據(jù)來判斷主庫是否可寫,是否可用,這就是常見的探測主庫實例是否活著的。
read_only=1,表示該實例為從庫。每隔一段時間探活,往往只會對從庫進(jìn)行讀操作,比如select 1;這樣進(jìn)行探活從庫。
所以,read_only
這個屬性其實并不適合用來做備份,而且如果使用了 read_only
屬性將整個庫設(shè)置為 readonly 之后,如果客戶端發(fā)生異常,則數(shù)據(jù)庫就會一直保持 readonly 狀態(tài),這樣會導(dǎo)致整個庫長時間處于不可寫狀態(tài),風(fēng)險很高。
因此這種方案不合格。
全局鎖,顧名思義,就是把整個庫鎖起來,鎖起來的庫就不能增刪改了,只能讀了。
那么我們看看怎么使用全局鎖。MySQL 提供了一個加全局讀鎖的方法,命令是 flush tables with read lock
(FTWRL)。當(dāng)你需要讓整個庫處于只讀狀態(tài)的時候,可以使用這個命令,之后其他線程的增刪改等操作就會被阻塞。
從圖中可以看到,使用 flush tables with read lock;
指令可以鎖定表;使用 unlock tables;
指令則可以完成解鎖操作(會話斷開時也會自動解鎖)。
和第一小節(jié)的方案相比,F(xiàn)TWRL 有一點(diǎn)進(jìn)步,即:執(zhí)行 FTWRL 命令之后如果客戶端發(fā)生異常斷開,那么 MySQL 會自動釋放這個全局鎖,整個庫回到可以正常更新的狀態(tài),而不會一直處于只讀狀態(tài)。
但是!??!
加了全局鎖,就意味著整個數(shù)據(jù)庫在備份期間都是只讀狀態(tài),那么在數(shù)據(jù)庫備份期間,業(yè)務(wù)就只能停擺了。
所以這種方式也不是最佳方案。
不知道小伙伴們是否還記得松哥之前和大家分享的數(shù)據(jù)庫的隔離級別,四種隔離級別中有一個是可重復(fù)讀(REPEATABLE READ)
,這也是 MySQL 默認(rèn)的隔離級別。
在這個隔離級別下,如果用戶在另外一個事務(wù)中執(zhí)行同條 SELECT 語句數(shù)次,結(jié)果總是相同的。(因為正在執(zhí)行的事務(wù)所產(chǎn)生的數(shù)據(jù)變化不能被外部看到)。
換言之,在 InnoDB 這種支持事務(wù)的存儲引擎中,那么我們就可以在備份數(shù)據(jù)庫之前先開啟事務(wù),此時會先創(chuàng)建一致性視圖,然后整個事務(wù)執(zhí)行期間都在用這個一致性視圖,而且由于 MVCC 的支持,備份期間業(yè)務(wù)依然可以對數(shù)據(jù)進(jìn)行更新操作,并且這些更新操作不會被當(dāng)前事務(wù)看到。
在可重復(fù)讀的隔離級別下,即使其他事務(wù)更新了表數(shù)據(jù),也不會影響備份數(shù)據(jù)庫的事務(wù)讀取結(jié)果,這就是事務(wù)四大特性中的隔離性,這樣備份期間備份的數(shù)據(jù)一直是在開啟事務(wù)時的數(shù)據(jù)。
具體操作也很簡單,使用 mysqldump 備份數(shù)據(jù)庫的時候,加上 -–single-transaction
參數(shù)即可。
為了看到 -–single-transaction
參數(shù)的作用,我們可以先開啟 general_log
,general_log
即 General Query Log,它記錄了 MySQL 服務(wù)器的操作。當(dāng)客戶端連接、斷開連接、接收到客戶端的 SQL 語句時,會向 general_log
中寫入日志,開啟 general_log
會損失一定的性能,但是在開發(fā)、測試環(huán)境下開啟日志,可以幫忙我們加快排查出現(xiàn)的問題。
通過如下查詢我們可以看到,默認(rèn)情況下 general_log
并沒有開啟:
我們可以通過修改配置文件 my.cnf(Linux)/my.ini(Windows)
,在 mysqld
下面增加或修改(如已存在配置項)general_log
的值為1,修改后重啟 MySQL 服務(wù)即可生效。
也可以通過在 MySQL 終端執(zhí)行 set global general_log = ON
來開啟 general log
,此方法可以不用重啟 MySQL
。
開啟之后,默認(rèn)日志的目錄是 mysql 的 data 目錄,文件名默認(rèn)為 主機(jī)名.log
。
接下來,我們先來執(zhí)行一個不帶 -–single-transaction
參數(shù)的備份,如下:
mysqldump -h localhost -uroot -p123 test08 > test08.sql
大家注意默認(rèn)的 general_log
的位置。
接下來我們再來加上 -–single-transaction
參數(shù)看看:
mysqldump -h localhost -uroot -p123 --single-transaction test08 > test08.sql
大家看我藍(lán)色選中的部分,可以看到,確實先開啟了事務(wù),然后才開始備份的,對比不加 -–single-transaction
參數(shù)的日志,多了開啟事務(wù)這一部分。
感謝各位的閱讀,以上就是“MySQL怎么保證備份數(shù)據(jù)的一致性”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對MySQL怎么保證備份數(shù)據(jù)的一致性這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關(guān)知識點(diǎn)的文章,歡迎關(guān)注!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。