主頁(yè) > 知識(shí)庫(kù) > 基于Redo Log和Undo Log的MySQL崩潰恢復(fù)解析

基于Redo Log和Undo Log的MySQL崩潰恢復(fù)解析

熱門(mén)標(biāo)簽:話務(wù)外呼系統(tǒng)怎么樣 智能外呼系統(tǒng)復(fù)位 大眾點(diǎn)評(píng)星級(jí)酒店地圖標(biāo)注 臨清電話機(jī)器人 拉卡拉外呼系統(tǒng) 高清地圖標(biāo)注道路 外東北地圖標(biāo)注 400電話可以辦理嗎 云南電商智能外呼系統(tǒng)價(jià)格

MySQL崩潰恢復(fù)流程

Buffer Pool是MySQL內(nèi)存結(jié)構(gòu)中十分核心的一個(gè)組成,你可以先把它想象成一個(gè)黑盒子。

1、黑盒下的更新數(shù)據(jù)流程

當(dāng)我們查詢(xún)數(shù)據(jù)的時(shí)候,會(huì)先去Buffer Pool中查詢(xún)。如果Buffer Pool中不存在,存儲(chǔ)引擎會(huì)先將數(shù)據(jù)從磁盤(pán)加載到Buffer Pool中,然后將數(shù)據(jù)返回給客戶(hù)端;同理,當(dāng)我們更新某個(gè)數(shù)據(jù)的時(shí)候,如果這個(gè)數(shù)據(jù)不存在于Buffer Pool,同樣會(huì)先數(shù)據(jù)加載進(jìn)來(lái),然后修改修改內(nèi)存的數(shù)據(jù)。被修改過(guò)的數(shù)據(jù)會(huì)在之后統(tǒng)一刷入磁盤(pán)。

MySQL 奔潰恢復(fù):

這個(gè)過(guò)程看似沒(méi)啥問(wèn)題,實(shí)則不講武德。假設(shè)我們修改Buffer Pool中的數(shù)據(jù)成功,但是還沒(méi)來(lái)得及將數(shù)據(jù)刷入磁盤(pán)MySQL就掛了怎么辦?按照上圖的邏輯,此時(shí)更新之后的數(shù)據(jù)只存在于Buffer Pool中,如果此時(shí)MySQL宕機(jī)了,這部分?jǐn)?shù)據(jù)將會(huì)永久的丟失;

再者,我更新到一半突然發(fā)生錯(cuò)誤了,想要回滾到更新之前的版本,該怎么辦?那不完?duì)僮訂?,連數(shù)據(jù)持久化的保證、事務(wù)回滾都做不到還談什么崩潰恢復(fù)?

2、Redo Log Undo Log

而通過(guò)MySQL能夠?qū)崿F(xiàn)崩潰恢復(fù)的事實(shí)來(lái)看,MySQL必定實(shí)現(xiàn)了某些騷操作。沒(méi)錯(cuò),這就是接下來(lái)我們要介紹的另外的兩個(gè)關(guān)鍵功能,Redo LogUndo Log。

這兩種日志是屬于InnoDB存儲(chǔ)引擎的日志,和MySQL Server的Binlog不是一個(gè)維度的日志。

(1)Redo Log 記錄了此次事務(wù)「完成后」的數(shù)據(jù)狀態(tài),記錄的是更新之「后」的值
(2)Undo Log 記錄了此次事務(wù)「開(kāi)始前」的數(shù)據(jù)狀態(tài),記錄的是更新之「前」的值
所以這兩種日志有明顯的區(qū)別,我用一種更加通俗的例子來(lái)解釋一下這兩種日志。

Redo Log就像你在命令行敲了很長(zhǎng)的命令,敲回車(chē)執(zhí)行,結(jié)果報(bào)錯(cuò)了。此時(shí)我們只需要再敲個(gè)↑就會(huì)拿到上一條命令,再執(zhí)行一遍即可。

Undo Log就像你剛剛在Git中Commit了一下,然后再做一個(gè)較為復(fù)雜的改動(dòng),但是改著改著你的心態(tài)崩了,不想要?jiǎng)倓偟母膭?dòng)了,于是直接git reset --hard $lastCommitId回到了上一個(gè)版本。

3、實(shí)現(xiàn)日志后的更新流程

有了Redo Log和Undo Log,我們?cè)賹⑸厦娴哪菑垐D給完善一下。

MySQL 崩潰恢復(fù):

首先,更新數(shù)據(jù)還是會(huì)判斷數(shù)據(jù)是否存在于Buffer Pool中,不存在則加載。上面我們提到了回滾的問(wèn)題,在更新Buffer Pool中的數(shù)據(jù)之前,我們需要先將該數(shù)據(jù)事務(wù)開(kāi)始之前的狀態(tài)寫(xiě)入U(xiǎn)ndo Log中。假設(shè)更新到一半出錯(cuò)了,我們就可以通過(guò)Undo Log來(lái)回滾到事務(wù)開(kāi)始前。

然后執(zhí)行器會(huì)更新Buffer Pool中的數(shù)據(jù),成功更新后會(huì)將數(shù)據(jù)最新?tīng)顟B(tài)寫(xiě)入Redo Log Buffer中。因?yàn)橐粋€(gè)事務(wù)中可能涉及到多次讀寫(xiě)操作,寫(xiě)入Buffer中分組寫(xiě)入,比起一條條的寫(xiě)入磁盤(pán)文件,效率會(huì)高很多。

redo-log-buffer:

那為什么Undo Log不也搞一個(gè)Undo Log Buffer,也給Undo Log提提速,雨露均沾?那我們假設(shè)有這個(gè)一個(gè)Buffer存在于InnoDB,將事務(wù)開(kāi)始前的數(shù)據(jù)狀態(tài)寫(xiě)入了Undo Log Buffer中,然后開(kāi)始更新數(shù)據(jù)。

突然啪一下,很快啊,MySQL由于意外進(jìn)程退出了,此時(shí)會(huì)發(fā)生一件很尷尬的事情,如果更新的數(shù)據(jù)一部分已經(jīng)刷回磁盤(pán)了,但是此時(shí)事務(wù)沒(méi)有成功需要回滾,你發(fā)現(xiàn)Undo Log隨著進(jìn)程退出一起沒(méi)了,此時(shí)就沒(méi)有辦法通過(guò)Undo Log去做回滾。

那如果剛剛更新完內(nèi)存,MySQL就掛了呢?此時(shí)Redo Log Buffer甚至都可能沒(méi)有寫(xiě)入,即使寫(xiě)入了也沒(méi)有刷到磁盤(pán),Redo Log也丟了。

其實(shí)無(wú)所謂,因?yàn)橐馔忮礄C(jī),該事務(wù)沒(méi)有成功,既然事務(wù)事務(wù)沒(méi)有成功那就需要回滾,而MySQL重啟后會(huì)讀取磁盤(pán)上的Redo Log文件,將其狀態(tài)給加載到Buffer Pool中。而通過(guò)磁盤(pán)Redo Log文件恢復(fù)的狀態(tài)和宕機(jī)前事務(wù)開(kāi)始前的狀態(tài)是一樣的,所以是沒(méi)有影響的。然后等待事務(wù)commit了之后就會(huì)將Redo Log和Binlog刷到磁盤(pán)。

3、流程中仍然存在的問(wèn)題

你可能認(rèn)為到這一步就完美了,事實(shí)上則不然。假設(shè)我們?cè)趯edo Log刷入到磁盤(pán)之后MySQL突然宕機(jī)了,binlog還沒(méi)有來(lái)得及寫(xiě)入。此時(shí)重啟,Redo Log所代表的狀態(tài)就和Binlog所代表的狀態(tài)不一致了。Redo Log恢復(fù)到Buffer Pool中的某行的A字段是3,但是任何監(jiān)聽(tīng)其Binlog的數(shù)據(jù)庫(kù)讀取出來(lái)的數(shù)據(jù)確是2。

即使Redo Log和Binlog都寫(xiě)入文件了,但是這個(gè)時(shí)候MySQL所在的物理機(jī)活著VM宕機(jī)了,日志仍然會(huì)丟失?,F(xiàn)在的OS在你寫(xiě)入文件的時(shí)候,會(huì)先將改動(dòng)的內(nèi)容寫(xiě)入的OS Cache中,以此來(lái)提高效率。然后根據(jù)策略(受你配置的參數(shù)的影響)來(lái)將OS Cache中的數(shù)據(jù)刷入磁盤(pán)。

4、基于2PC的一致性保障

從這你可以發(fā)現(xiàn)一個(gè)關(guān)鍵的問(wèn)題,那就是必須保證Redo Log和Binlog在事務(wù)提交時(shí)的數(shù)據(jù)一致性,要么都存在,要么都不存在。MySQL是通過(guò) **2PC(two-phase commit protocol)**來(lái)實(shí)現(xiàn)的。

MySQL 崩潰恢復(fù):

簡(jiǎn)單介紹一下2PC,它是一種保證分布式事務(wù)數(shù)據(jù)一致性的協(xié)議,它中文名叫兩階段提交,它將分布式事務(wù)的提交拆分成了2個(gè)階段,分別是Prepare和Commit/Rollback。

就向兩個(gè)拳擊手開(kāi)始比賽之前,裁判會(huì)在中間確認(rèn)兩個(gè)選手的狀態(tài),類(lèi)似于問(wèn)你準(zhǔn)備好了嗎?得到確認(rèn)之后,裁判才會(huì)說(shuō)Fight

裁判詢(xún)問(wèn)選手的狀態(tài),對(duì)應(yīng)的是第一階段Prepare;得到了肯定的回答之后,裁判宣布比賽正式開(kāi)始,對(duì)應(yīng)的是第二階段Commit,但是如果有一方選手沒(méi)有準(zhǔn)備好,裁判會(huì)宣布比賽暫停,此時(shí)對(duì)應(yīng)的是第一階段失敗的情況,第二階段的狀態(tài)會(huì)變?yōu)?strong>Rollback。裁判就對(duì)應(yīng)2PC中的協(xié)調(diào)者Coordinator,選手就對(duì)應(yīng)參與者Participant。

下面我們通過(guò)一張圖來(lái)看一下整個(gè)流程:2PC刷入磁盤(pán)

Prepare階段,將Redo Log寫(xiě)入文件,并刷入磁盤(pán),記錄上內(nèi)部XA事務(wù)的ID,同時(shí)將Redo Log狀態(tài)設(shè)置為Prepare。Redo Log寫(xiě)入成功后,再將Binlog同樣刷入磁盤(pán),記錄XA事務(wù)ID。

Commit階段,向磁盤(pán)中的Redo Log寫(xiě)入Commit標(biāo)識(shí),表示事務(wù)提交。然后執(zhí)行器調(diào)用存儲(chǔ)引擎的接口提交事務(wù)。這就是整個(gè)過(guò)程。

5、驗(yàn)證2PC機(jī)制的可用性

這就是2PC提交Redo Log和Binlog的過(guò)程,那在這個(gè)期間發(fā)生了異常,2PC這套機(jī)制真的能保證數(shù)據(jù)一致性嗎?

假設(shè)Redo Log刷入成功了,但是還沒(méi)來(lái)得及刷入Binlog MySQL就掛了。此時(shí)重啟之后會(huì)發(fā)現(xiàn)Redo Log并沒(méi)有Commit標(biāo)識(shí),此時(shí)根據(jù)記錄的XA事務(wù)找到這個(gè)事務(wù),進(jìn)行回滾。

如果Redo Log刷入成功,而且Binlog也刷入成功了,但是還沒(méi)有來(lái)的及將Redo Log從Prepare改成Commit MySQL就掛了,此時(shí)重啟會(huì)發(fā)現(xiàn)雖然Redo Log沒(méi)有Commit標(biāo)識(shí),但是通過(guò)XID查詢(xún)到的Binlog卻已經(jīng)成功刷入磁盤(pán)了。

此時(shí),雖然Redo Log沒(méi)有Commit標(biāo)識(shí),MySQL也要提交這個(gè)事務(wù)。因?yàn)锽inlog一旦寫(xiě)入,就可能會(huì)被從庫(kù)或者任何消費(fèi)Binlog的消費(fèi)者給消費(fèi)。如果此時(shí)MySQL不提交事務(wù),則可能造成數(shù)據(jù)不一致。而且目前Redo Log和Binlog從數(shù)據(jù)層面上,其實(shí)已經(jīng)Ready了,只是差個(gè)標(biāo)志位。

到此這篇關(guān)于基于Redo Log和Undo Log的MySQL崩潰恢復(fù)解析的文章就介紹到這了,更多相關(guān)MySQL崩潰恢復(fù)流程內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

您可能感興趣的文章:
  • MySQL系列之redo log、undo log和binlog詳解
  • 詳解MySQL 重做日志(redo log)與回滾日志(undo logo)
  • MySQL 撤銷(xiāo)日志與重做日志(Undo Log與Redo Log)相關(guān)總結(jié)
  • MySQL中的redo log和undo log日志詳解
  • Mysql中undo、redo與binlog的區(qū)別淺析

標(biāo)簽:福州 溫州 無(wú)錫 揚(yáng)州 定西 三明 山西 阿里

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《基于Redo Log和Undo Log的MySQL崩潰恢復(fù)解析》,本文關(guān)鍵詞  基于,Redo,Log,和,Undo,的,MySQL,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《基于Redo Log和Undo Log的MySQL崩潰恢復(fù)解析》相關(guān)的同類(lèi)信息!
  • 本頁(yè)收集關(guān)于基于Redo Log和Undo Log的MySQL崩潰恢復(fù)解析的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章