注：文中有個易混淆的地方"事務"
- sql事務，即每次資料庫操作生成的事務，這個事務trx_id只在undolog里存盤，同時undolog維護了此事務是否完成的狀態，
- 日志持久化事務，為了保證redolog和binlog的一致性而用的Mysql內部獨立維護的2PC提交事務，這個xid只有在redolog和binlog持久化檔案中存盤，
各日志的存盤內容
閱讀前提：需要對mysql的資料存盤結構有一定了解，即資料頁的持久化和記憶體讀取邏輯，
binlog日志
binlog日志存盤的是對資料庫實際的資料操作，可以理解為存盤的所有的資料庫更新sql，
mysql默認不開啟binlog，binlog主要用于主從同步和與其他資料庫的資料共享（通過中間件監聽binlog），
undolog日志
undolog存盤的是事務的回滾資料，存盤的資料回滾的關鍵資訊，undolog資料存盤在undolog表空間中，也是通過資料頁的形式存盤，和普通的資料頁一樣，也會不定期的進行持久化，
undolog也通過頁存盤，有自己獨立的表空間，所以undolog記錄的時候，舊的undolog可能會被覆寫（當然mysql會保證未提交事務的undolog和用于mvvc的undolog是不會被覆寫的），同時也會生成相應的redolog，有的人理解為redolog里也存盤了undolog的日志，其實是不對的，這個日志只是用來恢復undolog表空間的，并不是undolog實際的日志，
redolog日志
redolog存盤的是對頁結構的更新日志，可以理解為記錄了資料頁里修改了哪幾個位元組，用于mysql崩潰后的資料恢復，資料存盤在ib_logfile中，
redolog中有一個重要引數即checkpoint_lsn記錄了哪些redolog對應的資料頁已經持久化了，是資料恢復的一個非常重要的引數，
同時為了保證資料持久化，事務提交時所有的redolog必須持久化，由于多個事務的redolog是可以穿插寫入的，這就導致有部分未提交的事務被刷盤了，
redolog和binlog的二階段提交
redolog和binlog的二階段提交主要是為了防止系統崩潰時，redolog寫完，binlog沒有寫，導致主從不一致的問題，
innodb維護了一套事務表（注意這里的事務不是mysql的事務，是redolog持久化的事務），redolog和binlog持久化時會生成一個新的事務，并分配一個xid即2PC事務id給這次持久化操作，
持久化流程
- redolog寫盤并存盤xid
- binlog寫盤并存盤xid，2PC事務標記已提交，redolog事務提交，
崩潰恢復
- 掃描最后一個binlog檔案，提取其中的xid；
- InnoDB 維持了狀態為Prepare的事務鏈表，將這些事務的xid和binlog中記錄的xid做比較，如果在binlog中存在則提交，不存在則回滾事務，
資料恢復流程 基于binlog redolog undolog
- 通過binlog的xid和事務鏈表中的事務xid比較，找到不存在的事務的xid，去redolog中把這些事務回滾（洗掉），
- 以checkpoint點的redolog為起點開始恢復資料，即恢復上圖checkpoint到binlog之間的redolog資料，
- 由于undolog資料頁的修改也記錄在redolog中，未寫盤的undolog資料頁也被恢復，
- 在undolog表空間中查詢未提交的事務（Sql事務）執行undolog日志進行回滾
- 資料恢復完成
參考資料：《MySQL是怎樣運行的》及其他網路資料
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/500470.html
標籤：其他
上一篇：mysql進階