MySQL笔记三-事务-redolog

redolog，即重做日志，用于实现事务的持久性，由重做日志缓存(redo log buffer)和重做日志文件（redo log file）两部分组成。

大致流程如下

需要注意的是

1，redo log 在事务执行过程中不断写入的，binlog是在事务提交时一次性写入的

2，redo log 固化到磁盘时，如果没有打开 O_DIRECT ,实际是从buffer写入文件系统缓存，然后进行一次fsync操作。所以磁盘的性能也决定了事务提交的性能。fysnc策略可通过inndodb_flush_log_at_trx_commit参数控制

3，redo log写入磁盘大部分是顺序写，数据库运行时也不需要读redo log,所以redolog的写入是很快的。undolog的写入是随机的。

 

redo是undo的逆过程么？ 不是，redo log 恢复的是提交事务修改的页操作，undo log回滚行记录到某个版本。其次，redo log记录的是物理日志，undo log记录的是逻辑日志

 

什么时候 log buffer会把log刷新到磁盘呢？ 1，事务提交时（要保证ACID）2，log buffer有一半内存被使用时（内存容量，因为redolog在内存里页没啥用，不需要太高阈值，而频繁的fsync对性能有影响，也不需要太低的阈值）；3，log check point 时（后面会说）

 

redo log 大部分是顺序写是什么意思？ 每个redo log file 的前2KB部分不保存log block信息，而是存储其他信息，如 log file header，checkpoint等。需要注意的是，这些信息只在第一个redo log file中存储，其余的不存储但会保留2KB的空位，所以说大部分是顺序写入的

 

每个redo log file? log group 为重做日志组，此为逻辑概念，实际为多个redo log file物理文件，名为ib_logfile0~2

 

checkpoint 是什么？ LSN代表着日志序列号，单调递增，代表着 1，redo log 写入的总量;  2,页的版本；3,checkpot的位置; ;

首先对于1，假设当前LSN为1000，写入100字节的redo log，那么LSN变为1100，故LSN代表redo log的总量，单位为字节。 

其次对于2，LSN不仅记录在redo log里，还存在于每个页上，在页的头部，有一个值FIL_PAGE_LSN，记录的是该页的LSN，表示该页最后刷新时的LSN的大小。前面说过redo log记录的是每个页的日志，所以可以通过页的的LSN判断是否需要对这个页做crash recover。例，页P1的LSN为1000，数据库启动时，innodb发现redo log 中这页的LSN为1300，那么意味着需要做recover操作，反之就不用。

最后对于3，通过show engine innodb status 可以看到三个LSN相关参数，log sequence number ,log flushed up to ,last checkpoint.他们分别代表当前的LSN，刷新到redo log file 的LSN和刷新到磁盘的LSN。

 

难道每次启动都需要完全扫一遍redo log么？不需要，last checkpoint参数代表着已经刷新到磁盘的LSN，所以只需要恢复 last checkpoint 到  log sequence number之间的日记即可。我有点疑惑所以详细说下，如果事务正常提交了，那么redo log刷新到磁盘没有问题，如果事务回滚了，这部分的redo log也已经记录了是否会有问题？比如lSN从1000记录到1300，事务从1300回滚到1000，不会出现这种情况，回滚时通过undo log完成，undo log本身也会记录redo log，所以即使回滚，LSN也是从1300到1600，而且之前也说了LSN是单调递增的，不可能减少。