搞懂MySQL的redolog座舍、binlog
為什么要redolog？
對(duì)于一般的理解而言陨帆，當(dāng)更新數(shù)據(jù)的時(shí)候曲秉，把數(shù)據(jù)寫入到磁盤就好了采蚀，為什么MySQL要先寫入redolog并更新內(nèi)存，在空閑的時(shí)候才再把redolog里的數(shù)據(jù)寫入磁盤呢承二？這里涉及到MySQL里經(jīng)常說到的WAL(Write-Ahead Logging)技術(shù)榆鼠，也就是先寫日志，因?yàn)閷懭罩臼亲芳硬僮骱ヰ恍枰诖疟P上追加一條日志即可妆够，而如果是直接將數(shù)據(jù)寫入磁盤，那么我們需要先找到原先數(shù)據(jù)存放在磁盤上的地址读虏，然后再寫入责静。顯然直接寫日志效率更高，redolog有點(diǎn)像是磁盤的緩存盖桥，先把要寫入的數(shù)據(jù)放到redolog里灾螃，當(dāng)系統(tǒng)空閑或是redolog寫滿了的時(shí)候，再把redolog寫入磁盤揩徊。
redolog的特性
- redolog是InnoDB引擎才有的腰鬼。
- redolog的大小是有限的，且是一個(gè)循環(huán)結(jié)構(gòu)塑荒，有一個(gè)write_pos和一個(gè)checkpoint熄赡，當(dāng)write_pos追上checkpoint的時(shí)候，表示redolog寫滿了齿税，這時(shí)MySQL必須將redolog里的內(nèi)容存儲(chǔ)到磁盤以給redolog騰出空間彼硫。
- redolog里寫的是物理日志，所謂物理日志指的是里面記錄的是磁盤數(shù)據(jù)頁上面的變化凌箕。
- redolog是保證MySQL crash-safe的重要因素拧篮。在MySQL崩潰后的恢復(fù)，主要靠的就是redolog和binlog來對(duì)MySQL進(jìn)行恢復(fù)的牵舱，保證數(shù)據(jù)的完整和一致串绩。
為什么要binlog？
binlog是MySQL恢復(fù)數(shù)據(jù)以及做備份庫的重要依據(jù)芜壁。例如當(dāng)我們想把數(shù)據(jù)恢復(fù)到今天8點(diǎn)整的狀態(tài)礁凡，這時(shí)候就要依賴binlog了，具體的操作流程是：
- 先建立備份庫
- 讀取MySQL的快照慧妄，如果我們每天0點(diǎn)做一次備份的話顷牌，那么就讀取今天0點(diǎn)的快照，把備份庫的數(shù)據(jù)先恢復(fù)到今天0點(diǎn)的狀態(tài)塞淹。
- 然后我們讀取binlog里從今天0點(diǎn)到8點(diǎn)的日志韧掩，執(zhí)行日志里的邏輯操作。
- 最后用備份庫替換掉原庫的數(shù)據(jù)窖铡。
這樣就能將數(shù)據(jù)恢復(fù)到今天8點(diǎn)的狀態(tài)了疗锐。
做備份庫的邏輯也是相似的，先讀取一個(gè)最近的快照费彼，在這個(gè)快照的基礎(chǔ)上滑臊，讀取binlog。
binlog的特性
- binlog是MySQL Server層的箍铲，因此不論什么引擎都可以使用binlog雇卷。
- binlog的大小理論上是沒有限制的(只要磁盤足夠大)，因?yàn)閎inlog就是一直追加寫邏輯操作日志颠猴，當(dāng)文件太大了关划，就換一個(gè)文件接著寫。
- binlog存儲(chǔ)的是邏輯日志翘瓮，也就是平常我們執(zhí)行的MySQL的語句贮折。
重要的兩階段提交
當(dāng)我們更新數(shù)據(jù)時(shí)，兩階段提交的具體流程：
- 更新操作先寫入redolog资盅，這時(shí)候這條log的狀態(tài)是prepared狀態(tài)
- 再將邏輯日志寫入binlog
- 最后在binlog寫好之后调榄，把redolog里的這條日志的狀態(tài)改為commit
為什么要兩階段提交？
我們?cè)囅胍幌潞强福僭O(shè)沒有兩階段提交每庆，我們先寫redolog再寫binlog，或者是先寫binlog再寫redolog今穿，會(huì)發(fā)生什么缤灵？
以update tab set v=v+1 where id=1為例(假設(shè)v之前的值為0)
- 先寫redolog，再寫binlog：如果在寫完redolog之后MySQL崩潰蓝晒，這時(shí)候binlog還沒有寫腮出，在MySQL恢復(fù)的時(shí)候，就會(huì)出現(xiàn)MySQL里v的值已經(jīng)是1了拔创，而binlog里并沒有update這條語句利诺，這樣如果我們要做數(shù)據(jù)備份，在備份的數(shù)據(jù)庫里v的值就還是0剩燥，這樣會(huì)導(dǎo)致數(shù)據(jù)的不一致慢逾。
- 先寫binlog，再寫redolog：如果在寫完binlog之后灭红，MySQL崩潰侣滩，這時(shí)候redolog還沒有寫，這樣在MySQL恢復(fù)后变擒，就會(huì)出現(xiàn)MySQL里v的值還是0君珠，可是binlog里有這條更新的log，也就意味著當(dāng)我們做備份庫的時(shí)候娇斑，備份庫里的v會(huì)是1策添，導(dǎo)致數(shù)據(jù)不一致材部。
那么兩階段提交又為什么能保證數(shù)據(jù)的一致性呢？
我們也對(duì)一些極端情況做一下分析：
- 假設(shè)寫完redolog prepared之后唯竹，MySQL崩潰乐导，這時(shí)候binlog沒有寫入，當(dāng)MySQL恢復(fù)的時(shí)候浸颓，發(fā)現(xiàn)redolog里有一條prepared的記錄物臂，可是binlog里并沒有相關(guān)的日志，這時(shí)候MySQL會(huì)丟棄這條prepared日志产上，也就是說當(dāng)這條語句并沒有執(zhí)行成功棵磷，最終MySQL里v還是0，而binlog里也每有這條更新的日志晋涣。
- 假設(shè)寫完binlog之后仪媒，在把redolog改為commit之前，MySQL崩潰姻僧，當(dāng)MySQL恢復(fù)的時(shí)候规丽，發(fā)現(xiàn)redolog里有prepared的日志，若prepared事務(wù)在從Binlog中得到的提交事務(wù)列表中撇贺，則在InnoDB層提交此事務(wù)赌莺，也就是說MySQL識(shí)別到這條prepared的redolog是有效的，這樣通過引擎查詢到的v值會(huì)是1松嘶，同時(shí)binlog里也有此事務(wù)的日志艘狭。
正是這樣兩階段提交保證了數(shù)據(jù)的一致性。
兩階段提交在跨系統(tǒng)維持?jǐn)?shù)據(jù)邏輯一致性時(shí)是很常用的方案翠订，對(duì)于平常工作中處理到類似問題時(shí)具有啟發(fā)性巢音。例如假設(shè)我們的數(shù)據(jù)庫是MySQL+redis來構(gòu)建的，存在一種需求是我們寫了MySQL之后尽超，要去寫redis官撼，同時(shí)我們希望這兩個(gè)操作具有一致性，也就是說我們希望他們要么都成功了似谁，要么都失敗了傲绣，不要在MySQL里寫成功了，而在redis里寫失敗了巩踏，最終造成數(shù)據(jù)不一致秃诵。這種情況我們就可以考慮借鑒兩階段提交這個(gè)機(jī)制。
