事務(wù)重做日志(redo log)與回滾日志(undo log)

查看事務(wù)日志：

show engine innodb status;
show engine innodb status\G;

查看日志文件設(shè)置狀態(tài)：

show variables like 'innodb_%';

• innodb_log_files_in_group:DB 中設(shè)置幾組事務(wù)日志，默認(rèn)是2；
• innodb_log_group_home_dir 事務(wù)日志存放目錄，不設(shè)置；
• ib_logfile0… 存放在數(shù)據(jù)文件目錄下 InnoDB 存儲(chǔ)引擎可將所有數(shù)據(jù)存放于 ibdata* 的共享表空間，也可將每張表存放于獨(dú)立的 .ibd 文件的獨(dú)立表空間；

注意：在 MySQL 中對(duì)于數(shù)據(jù)來(lái)說(shuō)，最為重要的是日志文件

redo log => ib_logfile0…
undo log => ibdata

重做日志

持久化

事務(wù)被提交，數(shù)據(jù)一定會(huì)被寫(xiě)入到數(shù)據(jù)庫(kù)中并持久存儲(chǔ)起來(lái)，通常來(lái)說(shuō)當(dāng)事務(wù)已經(jīng)被提交之后，就無(wú)法再次回滾了。

重做日志實(shí)現(xiàn)持久化

與原子性一樣，事務(wù)的持久性也是通過(guò)日志來(lái)實(shí)現(xiàn)的，MySQL 使用重做日志（ redo log ）實(shí)現(xiàn)事務(wù)的持久性，重做日志由兩部分組成，一是內(nèi)存中的重做日志緩沖區(qū)，因?yàn)橹刈鋈罩揪彌_區(qū)在內(nèi)存中，所以它是易失的；另一個(gè)就是在磁盤(pán)上的重做日志文件，它是持久的。

當(dāng)我們?cè)谝粋€(gè)事務(wù)中嘗試對(duì)數(shù)據(jù)進(jìn)行寫(xiě)時(shí)，它會(huì)先將數(shù)據(jù)從磁盤(pán)讀入內(nèi)存，并更新內(nèi)存中緩存的數(shù)據(jù)，然后生成一條重做日志并寫(xiě)入重做日志緩存，當(dāng)事務(wù)真正提交時(shí)，MySQL 會(huì)將重做日志緩存中的內(nèi)容刷新到重做日志文件，再將內(nèi)存中的數(shù)據(jù)更新到磁盤(pán)上，圖中的第4、5步就是在事務(wù)提交時(shí)執(zhí)行的。

重做日志執(zhí)行

在MySQL中事務(wù)執(zhí)行 commit 提交了之后，但是服務(wù)器宕機(jī)了，數(shù)據(jù)還沒(méi)有寫(xiě)入磁盤(pán)，在MySQL重啟服務(wù)之后會(huì)重新執(zhí)行這個(gè)重做日志寫(xiě)入數(shù)據(jù)。

回滾日志

原子性

通俗的解釋就是：一條繩子上的螞蚱。

專業(yè)性的解釋是：事務(wù)一系列的操作，要么全部執(zhí)行，要么都不執(zhí)行。

回滾日志實(shí)現(xiàn)原子性

想要保證事務(wù)的原子性，就需要在異常發(fā)生時(shí)，對(duì)已經(jīng)執(zhí)行的操作進(jìn)行回滾，而在 MySQL 中，恢復(fù)機(jī)制是通過(guò)回滾日志（ undo log ）實(shí)現(xiàn)的，所有事務(wù)進(jìn)行的修改都會(huì)先記錄到這個(gè)回滾日志中，然后再對(duì)數(shù)據(jù)庫(kù)中的對(duì)應(yīng)行進(jìn)行寫(xiě)入。

注意：系統(tǒng)發(fā)生崩潰、數(shù)據(jù)庫(kù)進(jìn)程直接被殺死后，當(dāng)用戶再次啟動(dòng)數(shù)據(jù)庫(kù)進(jìn)程時(shí)，還能夠立刻通過(guò)查詢回滾日志將之前未完成的事務(wù)進(jìn)行回滾，這也就需要回滾日志必須先于數(shù)據(jù)持久化到磁盤(pán)上，是我們需要先寫(xiě)日志后寫(xiě)數(shù)據(jù)庫(kù)的主要原因。

在日志文件中：在事務(wù)中使用的每一條 insert into 都對(duì)應(yīng)了一條 delete ，每一條 update 也對(duì)應(yīng)一條相反的 update 語(yǔ)句。

回滾日志執(zhí)行

• 1.手動(dòng)執(zhí)行回滾命令時(shí)會(huì)執(zhí)行。
• 2.如果程序在事務(wù)執(zhí)行之后，提交命令執(zhí)行之前出現(xiàn)了異常，在下次 MySQL 服務(wù)重啟的時(shí)候會(huì)執(zhí)行。

測(cè)試：在事務(wù)提交前停止mysql服務(wù)

然后我們停止MySQL服務(wù)：

停止成功；然后再開(kāi)啟 MySQL 服務(wù)：

啟動(dòng)成功，然后查詢一下數(shù)據(jù)：

沒(méi)有查詢到新增的數(shù)據(jù)；數(shù)據(jù)已經(jīng)丟失了，需要執(zhí)行了commit之后數(shù)據(jù)才不會(huì)丟失。

重做日志與回滾日志總結(jié)

到現(xiàn)在為止我們了解了 MySQL 中的兩種日志，回滾日志（ undo log ）和重做日志（ redo log ）；在數(shù)據(jù)庫(kù)系統(tǒng)中，事務(wù)的原子性和持久性是由事務(wù)日志（ transaction log ）保證的，在實(shí)現(xiàn)時(shí)也就是上面提到的兩種日志；欠著用于對(duì)事務(wù)的影響進(jìn)行撤銷，后者在錯(cuò)誤處理時(shí)對(duì)已經(jīng)提交的事務(wù)進(jìn)行重做，它們能保證兩點(diǎn)：

發(fā)生錯(cuò)誤或者需要回滾的事務(wù)能夠成功回滾（原子性）。在事務(wù)提交后，數(shù)據(jù)沒(méi)來(lái)得及寫(xiě)入磁盤(pán)就宕機(jī)時(shí)，在下次重新啟動(dòng)后能夠成功恢復(fù)數(shù)據(jù)（持久性）。

在數(shù)據(jù)庫(kù)中，這兩種日志經(jīng)常都是一起工作的，我們可以將他們整體看作一條事務(wù)日志，其中包含了事務(wù)的ID、修改的行元素以及修改前后的值。

總結(jié) 

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論