MySQL中的 redo 日志檔案
MySQL中有三種日志檔案，redo log、bin log、undo log，redo log 是 存盤引擎層(innodb)生成的日志，主要為了保證資料的可靠性；bin log 是 MySQL 資料庫層面上生成的日志，主要用于 point in time 恢復和主從復制，undo log 主要用于事務的回滾(undo log 記錄的是每個修改操作的逆操作) 和 一致性非鎖定讀(undo log 回滾行記錄到某種特定的版本---MVCC 多版本并發控制)，
redo log 和 undo log 都是存盤引擎層面上生成的日志，并且都記錄了資料的修改：只不過 redo log記錄的是"物理級別"上的頁修改操作，比如頁號xxx、偏移量yyy寫入了'zzz'資料；而undo log 記錄的是邏輯操作日志，比如對某一行資料進行了INSERT陳述句操作，那么 undo log就記錄一條與之相反的DELETE操作，
redo log 作用---保證事務的持久性
MySQL作為一個存盤系統，為了保證資料的可靠性，最終得落盤，但是，又為了資料寫入的速度，需要引入基于記憶體的"緩沖池"，其實不止MySQL，這種引入緩沖來解決速度問題的思想無處不在，既然資料是先快取在緩沖池中，然后再以某種方式重繪到磁盤，那么就存在因宕機導致的緩沖池中的資料丟失，為了解決這種情況下的資料丟失問題，引入了redo log，在其他存盤系統，比如Elasticsearch中，也有類似的機制，叫translog，
但是一般討論資料寫入時，在MySQL中，一般叫事務操作，根據事務的ACID特性，如何保證一個事務提交后Durability的保證？而這就是 redo log 的作用，當向MySQL寫用戶資料時，先寫redo log，然后redo log根據"某種方式"持久化到磁盤，變成redo log file，用戶資料則在"buffer"中(比如資料頁、索引頁)，如果發生宕機，則讀取磁盤上的 redo log file 進行資料的恢復，從這個角度來說，MySQL 事務的持久性是通過 redo log 來實作的，
redo log 寫入磁盤
在事務運行程序中，會不斷地產生 redo log，這些 redo log 會先定入 redo log buffer中，然后再將 redo log buffer 中的資料以某些方式順序地寫入到磁盤（各個操作的redo log 匯總到 redo log buffer，再由 redo log buffer 統一寫磁盤，就能做到順序寫了），這些方式有：
-
MySQL master 執行緒周期性任務 每秒一次，將 redo log buffer 重繪到磁盤(即使這個事務尚未提交)
-
MySQL master 執行緒周期性任務 每10秒一次，將 redo log buffer 重繪到磁盤
-
當redo log buffer size 剩余空間小于1/2時(innodb_log_buffer_size引數)，將 redo log buffer 重繪到磁盤
-
當 redo log file 大小已經達到某個域值快要"不可用"時（日志檔案組輪流寫檔案），觸發 async/sync flush checkpoint，及時將一些臟頁重繪到磁盤，并同時將redo log buffer重繪到磁盤，然后更新redo log file 相應的 log sequence number值，
redo log buffer 的重繪到磁盤的時機由引數 innodb_flush_log_at_trx_commit 引數控制，可取的值有：0、1、2：
- 0 由master 執行緒周期性任務重繪
- 1 在事務 commit 時 redo log buffer 同步寫入 disk，伴隨 fsync 呼叫
- 2 將 redo log 日志資料異步寫入 disk，即只寫到檔案系統快取中，在事務成功提交后并不能保證 redo log 資料一定存盤到磁盤上了
redo log 寫入磁盤時，是以扇區大小512B寫入的，保證每次寫都能寫入成功，不需要有 double write 機制，
redo log buffer 與資料頁、索引頁、何時刷盤的區別？
Innodb存盤引擎基于緩沖池來平衡CPU與磁盤之間的速度差距，提高資料庫的性能，資料頁、索引頁屬于緩沖池的一部分，而redo log buffer其實也是一塊記憶體結構，redo log 的作用是用于故障恢復，實作事務的持久性機制，MySQL宕機了，從 redo log 檔案中讀取資料進行恢復，所以我們看到：innodb_flush_log_at_trx_commit=1時，每當事務提交時，就會記錄一些資訊到 redo log buffer，并且 fsync 寫磁盤，事務提交，修改了很多用戶資料，這些用戶資料是在資料頁、索引頁 這樣的緩沖池中，這些頁是通過LRU演算法來管理的（LRU List、Free List、Flush List），這些頁的刷盤是由checkpoint機制來管理的，不要與redo log buffer刷盤策略混淆，
說起checkpoint，一般都會提到：WAL（write ahead log）即：當事務提交時，先寫redo log，再修改頁（這里的頁，就是緩沖池中的資料頁、索引頁），
為什么？就是因為redo log 可以做到：每次寫redo log 時，可以同步寫入disk(伴隨fsync呼叫)，也就是innodb_flush_log_at_trx_commit引數設定為1的情形，
而我們緩沖池中的資料頁、索引頁是沒法做到，每修改一個頁就fsync重繪磁盤的，原因是：
倘若每次一個頁發生變化，就將新頁的版本重繪到磁盤，那么這個開銷是很大的，同時，從緩沖池將頁的新版本重繪到磁盤時發生了宕機，那么資料就不能恢復了，
這個時候，你可能會反問？那難道：每寫一次redo log就重繪一次磁盤，難道開銷就很小了？我的理解是：
資料頁、索引頁的刷盤是不容易的，因為底層是一棵B+樹結構，資料頁的刷盤要做到磁盤的順序寫，是要很多優化技巧的，而redo log的格式，是固定的，MySQL定義了redo log日志的各個欄位，再通過redo log buffer，很容易做到順序寫刷盤，并且，相比于資料頁、索引頁的中的內容，redo log的內容要簡單得多，
另外，還想解釋一下前文的那句話，為什么說：從緩沖池將頁的新版本重繪到磁盤時發生了宕機，那么資料就不能恢復了？
MySQL針對資料頁的寫入有一個：double write 機制（雙寫），因為資料頁大小是16KB，如果一個資料頁只寫了前面4KB就宕機，就是部分寫失效，前面提到 redo log記錄的是物理級別上的頁操作，而現在這個頁只寫了4KB，本身就是一個有"故障"的頁，那么 redo log 對這個頁的寫操作的記錄本身就是錯誤的，因此，就有了double write：資料頁先copy到double write buffer，先將資料頁順序寫共享表空間，然后再寫一份到該資料所對應的表空間中，如下圖所示：
而 redo log寫入磁盤時，是按512個位元組（一個磁盤扇區大小）寫入的，扇區是寫入的最小單位，因此可以保證寫入是必定成功的，不需要 double write buffer，
其實，寫到這里：解決了我心里很久的一個疑問，程式產生的資料都是先在記憶體里面，然后從記憶體里面持久化到磁盤的，如果行程突然掛了，為什么說資料還能不丟失呢？想想事務的持久性：只要事務提交了，那么產生的結果就是永久性的，就算MySQL行程被突然kill了，也能恢復，
不管是MySQL還是ES，都有checkpoint機制，當服務行程掛掉時，從redo log 或者translog上恢復資料，當發生故障時，到底要從redo log的哪個位置處開始恢復呢？它們都有一個叫做LSN(log sequence number)檢查點的東西，它表示在LSN之前的資料(緩沖池中的資料頁、索引頁)都已經持久化到磁盤了，而LSN之后的資料，尚未來得及fsync到磁盤，因此發生故障時需要讀取LSN之后的 redo log日志檔案進行恢復，
最后留一個思考，關于存盤系統的可靠性與可用性，同樣作為存盤系統，ElasticSearch里面有Translog，為什么Kafka里面沒有類似于redo log的保證資料可靠性機制呢？
ES也是分布式多副本，副本的復制也是基于PacificA演算法，但是ES中有Translog用來進行資料恢復，為什么Kafka沒有？想想涉及 Kafka Producer寫入 資料可靠性保證機制2個引數：ack=all 和 min.insync.replica，再看看 ES里面的2個引數 wait_for_active_shards 和 index.translog.durability 就能知道一些原因了，（wait_for_active_shards引數 涉及到"競態條件"check-and-then 它并不是原子的）
原文：https://www.cnblogs.com/hapjin/p/11521506.html
參考：《MySQL技術內幕》
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/6659.html
標籤：其他
上一篇：關于浮點數的轉換的問題