一：redo log(重做日志 是物理日志 InnoDB特有的日志)
數(shù)據(jù)庫中很多表其實(shí)是放在磁盤的，只有一少部分使用的時候才調(diào)入內(nèi)存辜羊。如果我們需要修改表的信息要怎樣做呢？首先是在內(nèi)存中修改表的信息吧词顾，其次找到磁盤表對應(yīng)的位置八秃，在上面update表的信息吧。對磁盤操作時很慢的啊计技，那有啥辦法可以解決這個問題呢喜德？redo log出現(xiàn)了。
1.redo log是用來干啥的
redo log可以保存數(shù)據(jù)庫執(zhí)行的指令，并把在內(nèi)存中的表的信息更新了吮成，但是不去更新磁盤上表的信息分井。那啥時候去更新呢？等系統(tǒng)自己空閑的時候再自動進(jìn)行磁盤讀寫速种。InnoDB的redo log是固定大小的，比如可以配置為一組4個文件，每個文件的大小是1GB它抱，那么總共就可以記錄4GB的操作。
2.redo log滿了咋處理
redo log寫滿了朴艰，系統(tǒng)沒法辦法只能停下來去把信息更新到磁盤上观蓄。留出一些空間留繼續(xù)保存新的命令。
3.Crash-safe
有了redo log祠墅，InnoDB就可以保證即使數(shù)據(jù)庫發(fā)生異常重啟侮穿，之前提交的記錄都不會丟失，這個能力稱為crash-safe毁嗦。
二：bindo log(歸檔日志 是邏輯日志)
MySQL自帶的引擎是MyISAM亲茅，但是MyISAM沒有crash-safe的能力，binlog日志只能用于歸檔。而InnoDB是另一個公司以插件形式引入MySQL的克锣，既然只依靠binlog是沒有crash-safe能力的茵肃，所以InnoDB使用另外一套日志系統(tǒng)——也就是redo log來實(shí)現(xiàn)crash-safe能力。binlog會記錄所有的邏輯操作袭祟，并且是采用追加寫的形式验残。主要用于數(shù)據(jù)庫恢復(fù)到某一個時刻，當(dāng)然這樣的前提是有這段時間的binlog巾乳。
三：redo log和bindo log的對比
- redo log是InnoDB引擎特有的您没；binlog是MySQL的Server層實(shí)現(xiàn)的，所有引擎都可以使用想鹰。
- redo log是物理日志紊婉，記錄的是“在某個數(shù)據(jù)頁上做了什么修改”；binlog是邏輯日志辑舷，記錄的是這個語句的原始邏輯喻犁，比如“給ID=2這一行的c字段加1 ”。
- redo log是循環(huán)寫的何缓，空間固定會用完肢础；binlog是可以追加寫入的÷道“追加寫”是指binlog文件寫到一定大小后會切換到下一個传轰，并不會覆蓋以前的日志。
四：兩階段提交
1.定義
redo log的寫入拆成了兩個步驟：prepare和commit谷婆。對于要寫入redolog的新行：
2.詳述
先來回顧下經(jīng)典的2PC協(xié)議慨蛙，有兩個角色：一個協(xié)調(diào)者（coordinator）和若干參與者（participant），協(xié)議執(zhí)行可以分為如下幾個階段：
預(yù)處理階段：嚴(yán)格來說纪挎，預(yù)處理階段并不是2PC的一部分期贫，在實(shí)際的分布式數(shù)據(jù)庫中，這個階段由協(xié)調(diào)者向若干參與者發(fā)送SQL請求或執(zhí)行計(jì)劃异袄，包括獲取行鎖通砍，生成redo數(shù)據(jù)等操作。
Prepare階段：客戶端向協(xié)調(diào)者發(fā)送事務(wù)提交請求烤蜕，協(xié)調(diào)者開始執(zhí)行兩階段提交封孙，向所有的事務(wù)參與者發(fā)送prepare命令，參與者將redo數(shù)據(jù)持久化成功后讽营，向協(xié)調(diào)者應(yīng)帶prepare成功虎忌。這里隱含的意思是，參與者一旦應(yīng)答prepare成功斑匪，就保證后續(xù)一定能夠成功執(zhí)行commit命令（redolog持久化成功自然保證了后續(xù)能夠成功commit）呐籽。
Commit階段
執(zhí)行Commit：協(xié)調(diào)者收到所有參與者應(yīng)答prepare成功的消息后锋勺，執(zhí)行commit，先在本地持久化事務(wù)狀態(tài)狡蝶，然后給所有的事務(wù)參與者發(fā)送commit命令庶橱。參與者收到commit命令后，釋放事務(wù)過程中持有的鎖和其他資源贪惹，將事務(wù)在本地提交（持久化一條commit日志）苏章，然后向協(xié)調(diào)者應(yīng)答commit成功。協(xié)調(diào)者收到所有參與者應(yīng)答commit成功的消息后奏瞬，向客戶端返回成功枫绅。
執(zhí)行Abort：prepare階段中如果有參與者返回prepare失敗或者超時未應(yīng)答，那么協(xié)調(diào)者將執(zhí)行abort硼端，同樣先在本地持久化事務(wù)狀態(tài)并淋，然后給所有參與者發(fā)送abort命令。參與者收到abort命令后珍昨，釋放鎖和其他資源县耽，將事務(wù)回滾（有必要的情況下還要持久化一條abort日志）。
3.為啥需要兩階段提交镣典？
這是為了讓兩份日志之間的邏輯一致兔毙。
你是不是會感覺bindolog多余？
但是binlog還不能去掉兄春。
一個原因是澎剥，redolog只有InnoDB有，別的引擎沒有赶舆。
另一個原因是哑姚，redolog是循環(huán)寫的，不持久保存芜茵，binlog的“歸檔”這個功能蜻懦，redolog是不具備的。
