搞懂MySQL的redolog、binlog
為什么要redolog？
對于一般的理解而言，當(dāng)更新數(shù)據(jù)的時候，把數(shù)據(jù)寫入到磁盤就好了，為什么MySQL要先寫入redolog并更新內(nèi)存，在空閑的時候才再把redolog里的數(shù)據(jù)寫入磁盤呢？這里涉及到MySQL里經(jīng)常說到的WAL(Write-Ahead Logging)技術(shù)，也就是先寫日志，因為寫日志是追加操作，只需要在磁盤上追加一條日志即可，而如果是直接將數(shù)據(jù)寫入磁盤，那么我們需要先找到原先數(shù)據(jù)存放在磁盤上的地址，然后再寫入。顯然直接寫日志效率更高，redolog有點像是磁盤的緩存，先把要寫入的數(shù)據(jù)放到redolog里，當(dāng)系統(tǒng)空閑或是redolog寫滿了的時候，再把redolog寫入磁盤。
redolog的特性
- redolog是InnoDB引擎才有的。
- redolog的大小是有限的，且是一個循環(huán)結(jié)構(gòu)，有一個write_pos和一個checkpoint，當(dāng)write_pos追上checkpoint的時候，表示redolog寫滿了，這時MySQL必須將redolog里的內(nèi)容存儲到磁盤以給redolog騰出空間。
- redolog里寫的是物理日志，所謂物理日志指的是里面記錄的是磁盤數(shù)據(jù)頁上面的變化。
- redolog是保證MySQL crash-safe的重要因素。在MySQL崩潰后的恢復(fù)，主要靠的就是redolog和binlog來對MySQL進行恢復(fù)的，保證數(shù)據(jù)的完整和一致。
為什么要binlog？
binlog是MySQL恢復(fù)數(shù)據(jù)以及做備份庫的重要依據(jù)。例如當(dāng)我們想把數(shù)據(jù)恢復(fù)到今天8點整的狀態(tài)，這時候就要依賴binlog了，具體的操作流程是：
- 先建立備份庫
- 讀取MySQL的快照，如果我們每天0點做一次備份的話，那么就讀取今天0點的快照，把備份庫的數(shù)據(jù)先恢復(fù)到今天0點的狀態(tài)。
- 然后我們讀取binlog里從今天0點到8點的日志，執(zhí)行日志里的邏輯操作。
- 最后用備份庫替換掉原庫的數(shù)據(jù)。
這樣就能將數(shù)據(jù)恢復(fù)到今天8點的狀態(tài)了。
做備份庫的邏輯也是相似的，先讀取一個最近的快照，在這個快照的基礎(chǔ)上，讀取binlog。
binlog的特性
- binlog是MySQL Server層的，因此不論什么引擎都可以使用binlog。
- binlog的大小理論上是沒有限制的(只要磁盤足夠大)，因為binlog就是一直追加寫邏輯操作日志，當(dāng)文件太大了，就換一個文件接著寫。
- binlog存儲的是邏輯日志，也就是平常我們執(zhí)行的MySQL的語句。
重要的兩階段提交
當(dāng)我們更新數(shù)據(jù)時，兩階段提交的具體流程：
- 更新操作先寫入redolog，這時候這條log的狀態(tài)是prepared狀態(tài)
- 再將邏輯日志寫入binlog
- 最后在binlog寫好之后，把redolog里的這條日志的狀態(tài)改為commit
為什么要兩階段提交？
我們試想一下，假設(shè)沒有兩階段提交，我們先寫redolog再寫binlog，或者是先寫binlog再寫redolog，會發(fā)生什么？
以update tab set v=v+1 where id=1為例(假設(shè)v之前的值為0)
- 先寫redolog，再寫binlog：如果在寫完redolog之后MySQL崩潰，這時候binlog還沒有寫，在MySQL恢復(fù)的時候，就會出現(xiàn)MySQL里v的值已經(jīng)是1了，而binlog里并沒有update這條語句，這樣如果我們要做數(shù)據(jù)備份，在備份的數(shù)據(jù)庫里v的值就還是0，這樣會導(dǎo)致數(shù)據(jù)的不一致。
- 先寫binlog，再寫redolog：如果在寫完binlog之后，MySQL崩潰，這時候redolog還沒有寫，這樣在MySQL恢復(fù)后，就會出現(xiàn)MySQL里v的值還是0，可是binlog里有這條更新的log，也就意味著當(dāng)我們做備份庫的時候，備份庫里的v會是1，導(dǎo)致數(shù)據(jù)不一致。
那么兩階段提交又為什么能保證數(shù)據(jù)的一致性呢？
我們也對一些極端情況做一下分析：
- 假設(shè)寫完redolog prepared之后，MySQL崩潰，這時候binlog沒有寫入，當(dāng)MySQL恢復(fù)的時候，發(fā)現(xiàn)redolog里有一條prepared的記錄，可是binlog里并沒有相關(guān)的日志，這時候MySQL會丟棄這條prepared日志，也就是說當(dāng)這條語句并沒有執(zhí)行成功，最終MySQL里v還是0，而binlog里也每有這條更新的日志。
- 假設(shè)寫完binlog之后，在把redolog改為commit之前，MySQL崩潰，當(dāng)MySQL恢復(fù)的時候，發(fā)現(xiàn)redolog里有prepared的日志，若prepared事務(wù)在從Binlog中得到的提交事務(wù)列表中，則在InnoDB層提交此事務(wù)，也就是說MySQL識別到這條prepared的redolog是有效的，這樣通過引擎查詢到的v值會是1，同時binlog里也有此事務(wù)的日志。
正是這樣兩階段提交保證了數(shù)據(jù)的一致性。
兩階段提交在跨系統(tǒng)維持數(shù)據(jù)邏輯一致性時是很常用的方案，對于平常工作中處理到類似問題時具有啟發(fā)性。例如假設(shè)我們的數(shù)據(jù)庫是MySQL+redis來構(gòu)建的，存在一種需求是我們寫了MySQL之后，要去寫redis，同時我們希望這兩個操作具有一致性，也就是說我們希望他們要么都成功了，要么都失敗了，不要在MySQL里寫成功了，而在redis里寫失敗了，最終造成數(shù)據(jù)不一致。這種情況我們就可以考慮借鑒兩階段提交這個機制。
