一汗茄、日志類型
邏輯日志：存儲了邏輯SQL修改語句
物理日志：存儲了數(shù)據(jù)被修改的值
二、binlog
1.定義
binlog 是 MySQL 的邏輯日志钠四，也叫二進制日志驴党、歸檔日志，由 MySQL Server 來記錄誊薄。
用于記錄用戶對數(shù)據(jù)庫操作的SQL語句（除了查詢語句）信息婉烟，以二進制的形式保存在磁盤中。
2.記錄方式
binlog 通過追加的方式寫入的暇屋，可通過配置參數(shù) max_binlog_size 設(shè)置每個 binlog 文件的大小似袁，當(dāng)文件大小大于給定值后，日志會發(fā)生滾動咐刨，之后的日志記錄到新的文件上昙衅。
3.格式
binlog 日志有三種格式，分別為 STATMENT定鸟、ROW 和 MIXED而涉。
| STATMENT | ROW | |
|---|---|---|
| 說明 | 基于SQL語句的復(fù)制(statement-based replication, SBR)，每一條會修改數(shù)據(jù)的sql語句會記錄到binlog中联予。是bin log的默認(rèn)格式啼县。 | 基于行的復(fù)制(row-based replication, RBR)：不記錄每一條SQL語句的上下文信息，僅保存哪條記錄被修改沸久。 |
| 優(yōu)點 | 不需要記錄每一條SQL語句與每行的數(shù)據(jù)變化季眷，減少了bin log的日志量，節(jié)約了磁盤IO卷胯，提高性能子刮。 | 會非常清楚的記錄下每一行數(shù)據(jù)修改的細(xì)節(jié)，不會出現(xiàn)某些特定情況下的存儲過程窑睁、或function挺峡、或trigger的調(diào)用和觸發(fā)無法被正確復(fù)制的問題葵孤。 |
| 缺點 | 在某些情況下會導(dǎo)致master-slave中的數(shù)據(jù)不一致，如sleep()函數(shù)橱赠， last_insert_id()尤仍，以及user-defined functions(udf)等會出現(xiàn)問題。 | 會產(chǎn)生大量的日志狭姨，尤其是alter table的時候會讓日志暴漲吓著。 |
MIXED模式是基于 STATMENT 和 ROW 兩種模式的混合復(fù)制(mixed-based replication, MBR)，一般的復(fù)制使用STATEMENT模式保存 binlog送挑，對于 STATEMENT 模式無法復(fù)制的操作使用ROW模式保存 binlog绑莺，MySQL 會根據(jù)執(zhí)行的 SQL 語句選擇日志保存方式。
三惕耕、redo log
1.定義：
redo log 是 MySQL 的物理日志纺裁，也叫重做日志，記錄存儲引擎 InnoDB 的事務(wù)日志司澎。
MySQL 每執(zhí)行一條 SQL 更新語句欺缘，不是每次數(shù)據(jù)更改都立刻寫到磁盤，而是先將記錄寫到 redo log 里面挤安，并更新內(nèi)存（這時內(nèi)存與磁盤的數(shù)據(jù)不一致谚殊，將這種有差異的數(shù)據(jù)稱為臟頁），一段時間后蛤铜，再一次性將多個操作記錄寫到到磁盤上嫩絮，這樣可以減少磁盤 io 成本，提高操作速度围肥。先寫日志剿干，再寫磁盤，這就是 MySQL 里經(jīng)常說到的 WAL 技術(shù)穆刻，即 Write-Ahead Logging置尔，又叫預(yù)寫日志。MySQL 通過 WAL 技術(shù)保證事務(wù)的持久性氢伟。
2.記錄方式
InnoDB 的 redo log 大小是固定的榜轿，采用循環(huán)寫的方式記錄，當(dāng)寫到結(jié)尾時朵锣，會回到開頭循環(huán)寫日志谬盐。如下圖：
write pos表示日志當(dāng)前記錄的位置，當(dāng)ib_logfile_4寫滿后猪勇，會從ib_logfile_1從頭開始記錄设褐；
check point表示將日志記錄的修改寫進磁盤，完成數(shù)據(jù)落盤泣刹，數(shù)據(jù)落盤后check point會將日志上的相關(guān)記錄擦除掉助析，
即write pos->check point之間的部分是redo log空著的部分，用于記錄新的記錄椅您，check point->write pos之間是redo log待落盤的數(shù)據(jù)修改記錄外冀。當(dāng)write pos追上check point時，得先停下記錄掀泳，先推動check point向前移動雪隧，空出位置記錄新的日志。
有了 redo log员舵，當(dāng)數(shù)據(jù)庫發(fā)生宕機重啟后脑沿，可通過 redo log 將未落盤的數(shù)據(jù)（check point之后的數(shù)據(jù)）恢復(fù)，保證已經(jīng)提交的事務(wù)記錄不會丟失马僻，這種能力稱為crash-safe庄拇。
四、兩階段提交
有了 redo log韭邓，為什么還需要 binlog 呢措近？先來看看 binlog 和redo log 的區(qū)別：
| redo log | binlog | |
|---|---|---|
| 文件大小 | redo log 的大小是固定的。 | binlog 可通過配置參數(shù)max_binlog_size 設(shè)置每個 binlog 文件的大小女淑。 |
| 實現(xiàn)方式 | redo log 是 InnoDB 引擎層實現(xiàn)的瞭郑，并不是所有引擎都有。 | binlog是 Server 層實現(xiàn)的鸭你，所有引擎都可以使用 binlog 日志屈张。 |
| 記錄方式 | redo log 采用循環(huán)寫的方式記錄，當(dāng)寫到結(jié)尾時袱巨，會回到開頭循環(huán)寫日志袜茧。日志上的記錄修改落盤后，日志會被覆蓋掉瓣窄，無法用于數(shù)據(jù)回滾/數(shù)據(jù)恢復(fù)等操作笛厦。 | binlog 通過追加的方式記錄，當(dāng)文件大小大于給定值后俺夕，日志會發(fā)生滾動裳凸，之后的日志記錄到新的文件上，不會覆蓋以前的記錄劝贸。 |
由 binlog 和 redo log 的區(qū)別可知：binlog 日志只用于歸檔姨谷，只依靠 binlog 是沒有 crash-safe 能力的。但只有 redo log 也不行映九，因為 redo log 是InnoDB 特有的梦湘，且日志上的記錄落盤后會被覆蓋掉。因此需要 binlog 和 redo log 二者同時記錄，才能保證當(dāng)數(shù)據(jù)庫發(fā)生宕機重啟時捌议，數(shù)據(jù)不會丟失哼拔。
當(dāng)執(zhí)行一條 SQL 更新語句時，過程如下：
可以看到瓣颅，在“兩階段提交”階段倦逐，將 redo log 的寫入分成了兩步：prepare 和 commit。在 redo log 狀態(tài)為 prepare 時記錄 binlog 可以保證兩個日志的記錄一致宫补。
五檬姥、如果數(shù)據(jù)庫誤操作, 如何執(zhí)行數(shù)據(jù)恢復(fù)?
DB宕機后重啟，InnoDB 會首先去查看數(shù)據(jù)頁中的LSN的數(shù)值粉怕。這個值代表數(shù)據(jù)頁被刷新回磁盤的 LSN 的大小健民。然后再去查看 redo log 的 LSN 的大小。
如果數(shù)據(jù)頁中的 LSN 值大說明數(shù)據(jù)頁領(lǐng)先于 redo log 刷新回磁盤贫贝，不需要進行恢復(fù)秉犹。反之需要從redo log中恢復(fù)數(shù)據(jù)。
注：LSN 是 日志序列號平酿， 為 log sequence number 的縮寫凤优，主要用于發(fā)生 crash 時對數(shù)據(jù)進行 recovery。LSN是一個一直遞增的整型數(shù)字蜈彼，表示事務(wù)寫入到日志的字節(jié)總量筑辨。
LSN 不僅只存在于重做日志中，在每個數(shù)據(jù)頁頭部也會有對應(yīng)的 LSN 號幸逆，該 LSN 記錄當(dāng)前頁最后一次修改的 LSN 號棍辕，用于在 recovery 時對比重做日志 LSN 號決定是否對該頁進行恢復(fù)數(shù)據(jù)。
前面說的check point也是由 LSN 號記錄的还绘，LSN 號串聯(lián)起一個事務(wù)開始到恢復(fù)的過程楚昭。
如果將 innodb_flush_log_at_trx_commit 和 sync_binlog 參數(shù)設(shè)置成 1，前者表示每次事務(wù)的 redo log 都直接持久化到磁盤拍顷，后者表示每次事務(wù)的 binlog 都直接持久化到磁盤抚太，可以雙重保證 MySQL 異常重啟之后的數(shù)據(jù)不會丟失。
