Innodb存储引擎--落盘整理

MySQL体系架构图

MySQL体系架构

Innodb体系架构

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