Part 1 What and Why

什么是redog和binlog?

redolog是對(duì)記錄修改之后的物理日志，物理日志就是說redolog保存的是某一行數(shù)據(jù)修改之后的值，比如把id=1這行的某個(gè)屬性由1改成2，redolog記錄的就是這個(gè)2.redolog是InnoDB引擎層的。

相比于redolog，binlog是邏輯日志。其中一種形式是記錄的原始sql語句，比如update t set c = c +1 where id = 1; binlog是數(shù)據(jù)庫server層的。

為什么需要redolog?

由于更新數(shù)據(jù)的時(shí)候引擎并不是按條更新的，而是以頁為最小單位更新。如果沒有redolog，每次更新一條數(shù)據(jù)都要把整頁的數(shù)據(jù)刷新到磁盤。如果更新多條數(shù)據(jù)，很可能一次就要更新多頁，而且這些io是隨機(jī)io，磁盤i/o就會(huì)多且慢。有了redolog，就不需要每次直接按頁更新磁盤，而是把更新寫到redolog中，然后等空閑時(shí)間再把redolog中的更新寫入到磁盤。這樣做的好處是redolog是順序?qū)懙模沂前礂l不是按頁寫。所以雖然多了一步，實(shí)際上是比直接更新快的。

為什么binlog不能做到crash-safe

假如只有binlog，有可能先提交事務(wù)再寫binlog，有可能事務(wù)提交數(shù)據(jù)更新之后數(shù)據(jù)庫崩了，還沒來得及寫binlog。我們都知道binlog一般用來做數(shù)據(jù)庫的主從復(fù)制或恢復(fù)數(shù)據(jù)庫，這樣就導(dǎo)致主從數(shù)據(jù)庫不一致或者無法恢復(fù)數(shù)據(jù)庫了。同樣即使先寫binlog再提交事務(wù)更新數(shù)據(jù)庫，還是有可能寫binlog成功之后數(shù)據(jù)庫崩掉而導(dǎo)致數(shù)據(jù)庫更新失敗，這樣也會(huì)導(dǎo)致主從數(shù)據(jù)庫不一致或者無法恢復(fù)數(shù)據(jù)庫。所以只有binlog做不到crash-safe。為了支持crash-safe，需要redolog，而且為了保證邏輯一致，事務(wù)提交需要兩個(gè)階段：prepare階段和commit階段。寫redolog并落入磁盤(prepare狀態(tài))-->寫binlog-->commit。commit的時(shí)候是不會(huì)落盤的。

那么為什么要在prepare階段就落盤呢？

如果binlog寫成功之后，將redolog置成commit的時(shí)候數(shù)據(jù)庫崩了，如果在commit的時(shí)候redolog才落盤，由于事務(wù)是否成功以binlog為依據(jù)，上面的情況下事務(wù)是成功的，但是redolog沒有寫到磁盤，丟了?；謴?fù)之后數(shù)據(jù)庫與binlog就不一致了。如果在prepare階段落盤，上面的情況下redolog已經(jīng)寫入到文件了（在prepare階段已經(jīng)寫盤了），恢復(fù)的時(shí)候不會(huì)丟數(shù)據(jù)。

同樣的，如果不分兩個(gè)階段。假如redolog和binlog獨(dú)立，那么還是會(huì)出現(xiàn)“為什么binlog不能做到crash-safe”里面描述的問題：數(shù)據(jù)庫與binlog不一致。

寫的比較粗略，細(xì)節(jié)很多沒寫，目的主要是為了解決自己的幾個(gè)疑問。需要讀者有redolog和binlog的基礎(chǔ)知識(shí)。