MySQL體系架構圖
Innodb體系架構
MySQL主要就是信息的持久化存儲，持久化就必須落盤，本篇文章
將整理介紹MySQL最重要的三個文件的落盤操作
Redo log 落盤
WAL(Write ahead redo log) 保障了事務的持久性，
必然，redo log的LSN > 數據(臟頁和落盤)LSN
innodb_log_buffer_size 控制redo log緩沖池大小
何時緩沖池中的數據落盤：
- master thread 每一秒，不論事務是否提交
- innodb_flush_log_at_trx_commit 控制每次事務提交時
=0：不落盤，等master thread的刷新
=1：fsync落盤，不丟失事務
=2：OS緩沖寫
innodb_flush_log_at_trx_commit示意圖.png
- 緩沖池剩余空間小于1/2時
redo log寫盤是磁盤扇區單位寫，不存在寫失敗的情況
Binlog 落盤
binlog 是mysql server的。與redo log無直接關系，且可以關閉
sync_binlog=[N]控制落盤的頻次，通過innodb_support_xa 協同binlog和innodb的redo log處理
**總結：理清redo log 和 binlog的層次，作用：
redo log是innodb獨立使用的，記錄的是數據頁的更改的物理情況
binlog是mysql的整個寫入操作，記錄的是mysql邏輯寫操作
sync_binlog，innodb_flush_log_at_trx_commit，innodb_support_xa。三者都設置為1(TRUE)，數據才能真正安全。sync_binlog非1，可能導致binlog丟失(OS掛掉)，從而與innodb層面的數據不一致。innodb_flush_log_at_trx_commit非1，可能會導致innodb層面的數據丟失(OS掛掉)，從而與binlog不一致。
**
data 落盤（數據頁&索引頁 ）
改進的LRU算法，得出哪些臟頁需要落盤
CheckPoint技術，實際的落盤操作
- sharp point
數據庫關閉時，刷盤，即innodb_fast_shutdown=1
- fuzzy point
master thread 1s 和 10s
LRU 列表沒有足夠的空閑頁
redo log 沒有足夠的可復用的空間時
對比redo log的LSN和落盤數據的LSN
臟頁率 > innodb_max_dirty_pages_pct
數據寫盤操作是double write，防止部分寫失效
double write （順序寫ibdata，隨機寫ibd）：
1、dirty pages memcpy到 double wirte buffer
2、doublewrite buffer 分兩次fsync 1M數據到共享表空間的double buffer（順序寫，fsync可以避免寫失效的問題）
3、doublewrite buffer 寫入到ibd數據文件（離散寫）
總結： redo log的落盤和data的落盤是獨立的操作單元，盡管它們可能在master thread有同時操作概率，它們之間的唯一協調處理在fuzzy checkpoint的第三個場景：redo log復用空間不夠了，導致了data落盤
Master Thread 工作流：
| 后臺線程 | relog 落盤 | 合并插入緩沖 | 刷臟頁 | purge undo段 |
|---|---|---|---|---|
| master 1s | ? | low IO | 臟頁>pct | ? |
| master 10s | ? | ? | low IO OR 臟頁>pct | ? |
| backgroud | ? | ? | ? | ? |
| flush loop | ? | ? | ? | ? |
