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 | ✘ | ✘ | ✔ | ✘ |
