一、redo log 的作用
磁盘上的数据文件叫表空间文件，表空间有挺多的，比如系统表空间、undo log 表空间、可以让create出来的每张table都有自己单独的表空间。总之MySQL会将表空间数据页通过磁盘IO加载进缓存页中。
SQL执行器会执行你发送给MySQL的SQL语句，MySQL为了提高的性能，对于增、删、改这种操作都是在内存中完成的，所谓的内存就是上图中BufferPool。比如上图中的SQL执行器执行了一条update xxx where id = 1语句，然后这个id = 1数据行所在的数据页就会被你修改成脏数据页。
此外MySQL还有专门的后台线程等其他机制负责将脏数据页刷新同步回磁盘。
结合上图想一下：万一脏页还没来得及刷新到磁盘中，MySQL就挂了，怎么办呢？
对于业务代码来说，方才执行的事务是OK的，甚至前端都接受到了请求成功的响应。那结果修改的数据没同步回磁盘，MySQL宕机了会不会导致真实数据和逻辑上的数据不一致呢？
其实不会！MySQL使用redo log解决了这个问题，redo故名思义：重做。
当发生事务（增、删、改）时会导致缓存页变成脏页，于此同时MySQL会将事务涉及到的：对 XXX表空间中的XXX数据页XXX偏移量的地方做了XXX更新保存在redo log。
所以MySQL意外宕机重启也没关系。只要在重启时解析redo log中的事务然后重放一遍。将Buffer Pool中的缓存页重做成脏页。后续再在合适的时机将该脏页刷入磁盘即可。
redo log侧重于重做！redo log中记录的是物理层面的数据页、偏移量。应对的问题是：MySQL异常宕机后，如何将没来得及提交的事物数据重做出来。
而后面会讲的bin log中，记录的是你对XXX表条件为XXX处的数据作了什么修改，是逻辑上的概念。
二、redo log block
redo并不是一条条直接写入磁盘中去的！而是按块，一块一块的写入到磁盘中去的。可以类比一下数据是按页为单位来组织的，就更容易理解为啥redo log 要按照block来组织redo。本质上就是两个字：优化。
log block长成下面这这样：分成Header、Body、Trailer三部分，总共512字节。而且是覆盖写入。
MySQL会写redo log，说明你的sql会对缓存页造成修改，也就意味着会走MySQL设定的事务机制。如果每个增、删、改都会有一个对应的redo log的话，那一个事务会产生好多redolog。这些redo会先被持续不断的写入到log block中，同一个事务产生的redo log会被标记为一个redo log group。
三、redo log group
redo log group说的是：由N个大小相同的redo log组成一个redo log group。N的值默认为2。
可以通过 show variables like '%innodb_log%'; 查看MySQL的redo log group情况。
默认单个redo log文件的大小是48MB。你也可以通过上图中的innndb_log_files_size修改它。日志文件的总大小（innodb_log_file_size* innodb_log_files_in_group）不能超过略小于512GB的最大值。
四、redo log buffer
redo log buffer 中会划分出多个rodo log block。redo log buffer 占用一块连续的内存空间，默认大小16MB。且通过参数innodb_log_buffer_size动态的调整它。增大它的大小可以让MySQL处理大事务时不必写入磁盘。进而提升写IO性能。
如图，产生的redo log 先写入redo log block，然后redo log block其实就在redo log buffer 中。
看到这里不知道你有没有想到这样一个问题：redo log buffer再怎么神奇毕竟也是仅仅在内存中，此时万一MySQL宕机了怎么办？redolog-buffer中的数据丢失了怎么办？毕竟没有写到磁盘上，MySQL重启后100%没办法将其恢复出来。
其实你并不用担心这种情况！因为在MySQL的设定中，当你要Commit事务时，redolog才会持久化进磁盘，既然你没有commit，碰巧MySQL又宕机了。那让MySQL正常重启就好了啊，反正你没有commit，MySQL也也没有必要帮你恢复什么。
那 redo log buffer 何时写入磁盘呢？
- 事务提交时把它对应的那些redo log写入到磁盘中去，这个动作可由相关参数控制。
- 当redo log buffer 使用量达到了参数innndb_log_buffer_size的一半时，会触发落盘。
- 会有一个后台线程，每隔1秒就会将redo log block刷新到磁盘文件中去。
- MySQL关闭时也会将其落盘。
五、redo log的刷盘时机
承接上面描述的场景：事务提交时，率先将redo log持久化进磁盘。那你如何控制MySQL，让MySQL在Commit事务时率先将redo log持久化呢？
MySQL提供了参数 innodb_flush_log_at_trx_commit
- 设置为1：想要保证ACID四大特性推荐。表示当你commit时，MySQL必须将rodolog-buffer中的数据刷新进磁盘中。确保只要commit是成功的，磁盘上就得有对应的rodolog日志。这也是最安全的情况。
- 设置为0：每秒写一次日志并将其刷新到磁盘。
- 设置为2：表示当你commit时，将redolog-buffer中的数据刷新进OS Cache中，然后依托于操作系统每秒刷新一次的机制将数据同步到磁盘中，也存在丢失的风险。
推荐参数
- 始终设置 innodb_flush_log_at_trx_commit=1
- 如果启用了二进制日志记录，请设置 sync_binlog=1。
这也是大家常说的双1设置。前者保证redolog的不丢失、后者保证了binlog的不丢失。
关于sync_binlog参数，见bin log
六、redo log block刷盘
可以像下面这样查看磁盘上的 redo log 文件。它们的大小由 innodb_log_file_size 设置。
innodb将log buffer中的redo log block刷新到磁盘文件时，以追加的方式循环写入。先在ib_logfile0的尾部追加，写满后再写ib_logfile1。当ib_logfile1写满时，清除一部分ib_logfile0接着追加写。
redo log file的大小对innodb性能影响非常大。通常来说要设置的足够大，大到可以让MySQL支持1小时线上高峰流量的接入而不切换。但设置的过大，数据恢复的时间会比较长；设置过小导致循环切换redo log file。
redo log让mysql有了崩溃恢复的能力，结合checkpoint机制进行，见checkpoint机制
若有收获，就点个赞吧
0 人点赞
