innodb的logs：生成过程

　　这篇是25号参加互动出版和北京GDG举办的数据库分享会的个人总结。Qunaer的王竹峰先生分享了他对innodb的log的认识和总结，主要包括了下面部分:innodb日志生成，日志文件/格式，redo、undo、doublewrite。

innodb的日志

　　mysql server的日志包括:bin-log（二进制日志），relay-log（中继日志），slow-log（慢查询日志），log（查询日志），error-log（错误日志）。

　　innodb的日志除了上面五种类型，为了实现事务，提高io性能，增强数据安全，其他原因，增加了下面日志机制：log_buffer，log_file，redo log，undo_log，重点是这一部分。

innodb的日志生成

名词解释：

（1）checkpoint，最近一次被修改的page成功flush磁盘时候的lsn，需要了解：

　　1）每次数据页有变化并被flush进磁盘的时候，都会产生一个checkpoint。

　　2）innodb将修改页从buffer pool刷进data file的时候，是一批操作，而不是一次写入。

　　3）checkpoint采用Fuzzy Checkpoint，即每次取最早的dirty page，确认此page之前的page都已经刷入磁盘，以此page的lsn为checkpoint的点。

　　4）checkpoint被记录在logfile开始的固定偏移位置上，并覆盖之前的checkpoint点。

（2）lsn，在mysql中是log sequence number的缩写。

　　1）lsn在mysql 5.6.3以前是一个4字节的无符号整数，最大值是2^32，5.6.3及以后为8字节无符号整数，最大值为2^64。

　　2）实例初始化时刚创建时lsn为0（当时还没有ib_logfile），以后就按照写入的内容大小来增长，lsn=前1个lsn值+增量；

　　3）ib_logfile每次增长512字节。

　　4）操作写入log buffer时，产生新的lsn。

　　5）每次写入log buffer时，确认log buffer剩余空间是否够存放,不够，则把buffer里的内容刷入logfile。并更新log buffer的lsn，logfile的lsn。

（3）undo_log是待修改的原数据的一个备份，存放在共享空间ibdata中中的。当事务执行失败或rollback的时候，用undo_log将数据恢复到执行之前。

　　 undo_log记录的是完整的page还是待修改的数据行？是完整的page。

（4）redo_log事务日志，是对数据修改操作的备份，存放在ib_logfile*文件中，由innodb_log_file_size,innodb_log_files_in_group,innodb_log_group_home_dir三个参数定义，当然还有其他的参数。假设如下设置：

　　 innodb_log_file_size=256M

　　 innodb_log_files_in_group=3

定义了三个ib_logfile文件，logfile编号从0开始，每个大小256M，那么redo_log会按照下面顺序来日志：

先写入log_file0，之后logfile1，再满logfile2，再慢覆盖写logfile0，如此循环。

　　logfile的每次操作以512字节对齐。

　　redo_log记录的是什么？不是page，不是操作，是一种称作“生理”日志的记录，它的结构如下：

Type

spaceid

offset

data

　　Type：日志记录类型，1字节。最高位!
　　Space：表空间，compressed整形，1-5字节!
　　Offset：页号，compressed整形，1-5字节
　　Data: 根据不同的TYPE有不同的格式!

（5）undo的redo_log

innodb在修改page之前，会将数据行存放进undo_log空间，并且将这个操作记录进log_buffer，被存入redo_log，这个操作就是undo的redo_log。此操作被计入mtr中。在logfile中记录如下：

记录1: <trx1, Undo log insert <undo_insert …>>
记录2: <trx1, insert …>
记录3: <trx2, Undo log insert <undo_update …>>
记录4: <trx2, update …>
记录5: <trx3, Undo log insert <undo_delete …>>
记录6: <trx3, delete …>

（6）Miti-Transcation（MTR）

　　mysql操作的最小单元是数据页，每个操作可能是一个page或者n个page的连续操作，这些操作被包含在mtr中。mtr是在1或n个page上操作的集合，具有不可分割性，一致性。

　　1）一致性。在n个page上的操作不可分割时，这些page的操作记录被包含在同一个mtr中，一起被提交到redo log buffer。InnoDB在redo log的层面，将一个MTR中的所有日志作为Redo log的最小单元。在恢复时，一个MTR完整才能进行操作。

　　2）mtr的封装。如果一个mtr只对一个page操作，并且只有1行记录，那么在mtr开始添加MLOG_SINGLE_REC_FLAG；如果一个mtr有n行记录，则在mtr结尾添加MLOG_MULTI_REC_END。

　　3）一个mtr被提交到log_buffer后，mtr相关的page获取同一个lsn，并且这些page被加入buffer_pool的flush_list。

　 4）mtr加的page_lock确保同一个page同时只能被一个mtr访问。mtr提交之后（被计入log buffer），page锁被释放，锁类型包括mtr_s_lock或mtr_x_lock。

　　5）mtr不能回滚，只能提前预判执行会不会失败。

redo-log生成的流程，请看下图：

注:图是我自己查资料画的，肯定有很多不对的地方，尤其红色部分，自己没有确认过。

这个过程有4个lsn：

lsn1:mtr计入log_buffer的时候，对log_buffer的lsn进行更新。这个lsn也是mtr对应脏页上的lsn

lsn2:log_buffer刷进redo_log的时候，对redo_log的lsn进行更新。

lsn3:Dirty page被flush进datafile的时候，更新对应data page的lsn。

lsn4:在log_file中产生的CKP（checkpoint）的lsn。

同一时间点的这四个lsn有下面大小关系:lsn1 >= lsn2 >= lsn3 >= lsn4(ckp)

查看show engine innodb status\G;

---
LOG
---
Log sequence number 1632169
Log flushed up to   1632169
Pages flushed up to 1632169
Last checkpoint at  1632169
0 pending log writes, 0 pending chkp writes
8 log i/o's done, 0.00 log i/o's/second