MySQL-redo log日志

https://www.hyouit.com?aff=418

1、redo log

redo log（重做日志）是InnoDB存储引擎独有的，记录在某个数据页上做了什么修改，它让MySQL拥有了崩溃恢复能力。

MySQL中数据是以页为单位，你查询一条记录，会从硬盘把一页的数据加载出来，加载出来的数据叫数据页，会放入到Buffer Pool中。

后续的查询都是先从Buffer Pool中找，没有命中再去硬盘加载，减少硬盘IO开销，提升性能。

更新表数据的时候，也是如此，发现Buffer Pool里存在要更新的数据，就直接在Buffer Pool里更新。

然后会把“在某个数据页上做了什么修改”记录到重做日志缓存（redo log buffer）里，接着刷盘到redo log文件里。

2、redo log 刷盘机制

什么时候刷盘呢？理想情况，事务一提交就会进行刷盘操作，但实际上，刷盘的时机是根据策略来进行的。

InnoDB存储引擎为redo log的刷盘策略提供了innodb_flush_log_at_trx_commit参数，它支持三种策略

• 设置为0的时候，表示每次事务提交时不进行刷盘操作，如果MySQL挂了或宕机可能会有1秒数据的丢失。
• 设置为1的时候，表示每次事务提交时都将进行刷盘操作（默认值），只要事务提交成功，redo log记录就 一定在硬盘里，不会有任何数据丢失。如果事务执行期间MySQL挂了或宕机，这部分日志丢了，但是事务并没有提交，所以日志丢了也不会有损失。
• 设置为2的时候，表示每次事务提交时都只把redo log buffer内容写入page cache（文件系统缓存），只要事务提交成功，redo log buffer中的内容只写入文件系统缓存（page cache）。如果仅仅只是MySQL挂了不会有任何数据丢失，但是宕机可能会有1秒数据的丢失。

另外InnoDB存储引擎有一个后台线程，每隔1秒，就会把redo log buffer中的内容写到文件系统缓存（page cache），然后调用fsync刷盘。

也就是说，一个没有提交事务的redo log记录，也可能会刷盘。

为什么呢？因为在事务执行过程redo log记录是会写入redo log buffer中，这些redo log记录会被后台线程刷盘。

除了后台线程每秒1次的轮询操作，还有一种情况，当redo log buffer占用的空间即将达到innodb_log_buffer_size一半的时候，后台线程会主动刷盘。

每条redo记录由“表空间号+数据页号+偏移量+修改数据长度+具体修改的数据”组成

3、日志文件组

硬盘上存储的redo log日志文件不只一个，而是以一个日志文件组的形式出现的，每个的redo日志文件大小都是一样的。

比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写，如下面这个图所示。

它采用的是环形数组形式，从头开始写，写到末尾又回到头循环写。

在个日志文件组中还有两个重要的属性，分别是write pos、checkpoint

write pos是当前记录的位置，一边写一边后移
checkpoint是当前要擦除的位置，也是往后推移
每次刷盘redo log记录到日志文件组中，write pos位置就会后移更新。

每次MySQL加载日志文件组恢复数据时，会清空加载过的redo log记录，并把checkpoint后移更新。

write pos和checkpoint之间的还空着的部分可以用来写入新的redo log记录。

如果write pos追上checkpoint，表示日志文件组满了，这时候不能再写入新的redo log记录，MySQL得停下来，清空一些记录，把checkpoint推进一下。

4、redo log 意义

为什么不直接数据页刷盘，而是redo log刷盘呢？
实际上，数据页大小是16KB，刷盘比较耗时，可能就修改了数据页里的几Byte数据，有必要把完整的数据页刷盘吗？

而且数据页刷盘是随机写，因为一个数据页对应的位置可能在硬盘文件的随机位置，所以性能是很差。

如果是写redo log，一行记录可能就占几十Byte，只包含表空间号、数据页号、磁盘文件偏移 量、更新值，再加上是顺序写，所以刷盘速度很快。

所以用redo log形式记录修改内容，性能会远远超过刷数据页的方式，这也让数据库的并发能力更强。