参考：mysql日志系统之redo log和bin log - 简书
首先，我们先来看看一次查询/更新语句流程图
本文会将重点放在执行器<->存储引擎之间的交互。
- mysql不是每次数据更改都立刻写到磁盘，而是会先将修改后的结果暂存在内存中。当一段时间后，再一次性将多个修改写到磁盘上，减少磁盘io成本，同时提高操作速度。
同理，redolog你可以想象成两部分，内存一部分(redolog buffer)，磁盘上另外一个部分(redo log)。
- MySQL通过WAL(write-ahead logging)技术保证事务
参考：美团面经
为了防止断电导致数据丢失的问题，当有一条记录需要更新的时候，InnoDB 引擎就会先更新内存（同时标记为脏页），然后将本次对这个页的修改以 redo log 的形式记录下来，这个时候更新就算完成了。
后续，InnoDB 引擎会在适当的时候，由后台线程将缓存在 Buffer Pool 的脏页刷新到磁盘里，这就是 WAL （Write-Ahead Logging）技术。
WAL 技术指的是， MySQL 的写操作并不是立刻写到磁盘上，而是先写日志，然后在合适的时间再写到磁盘上。
在同一个事务中，每次进行修改数据操作时，将修改结果更新到内存redolog buffer后（会在redo log buffer中添加一行记录记录“需要在哪个数据页上做什么修改），并将该记录状态置为prepare，等到commit提交事务后，会将此次事务中在redo log添加的记录的状态都置为commit状态。之后在修改落盘时，会将redo log中状态为commit的记录的修改都从redolog buffer内存中写入redo log（磁盘）。
小结：先更新buffer内存，再写redo log，只不过这个阶段是prepare状态，等server层把binlog写入成功之后，提交事务，redo log才会从prepare变成commit。
过程如下图：
更新流程.png
- redo log记录方式
redolog的大小是固定的，在mysql中可以通过修改配置参数innodb_log_files_in_group和innodb_log_file_size配置日志文件数量和每个日志文件大小，redolog采用循环写的方式记录，当写到结尾时，会回到开头循环写日志。如下图
write pos表示日志当前记录的位置，当ib_logfile_4写满后，会从ib_logfile_1从头开始记录；check point表示将日志记录的修改写进磁盘，完成数据落盘，数据落盘后checkpoint会将日志上的相关记录擦除掉，即write pos->checkpoint之间的部分是redo log空着的部分，用于记录新的记录，checkpoint->write pos之间是redo log待落盘的数据修改记录。当writepos追上checkpoint时，得先停下记录，先推动checkpoint向前移动，空出位置记录新的日志。
有了redo log，当数据库发生宕机重启后，可通过redo log将未及时落入数据盘的缓冲区数据进行恢复，即保证已经提交的事务记录不会丢失。（因为只要有写操作，必然先去更新redo log，然后再去更新缓冲区数据。先后关系：redo log的更新先于缓冲区数据的更新）
问题1：有了redo log，为啥还需要binlog呢？
- redo log的大小是固定的，采用"循环滚动写"的方式记录log，日志上的记录修改落盘后，日志会被覆盖掉，无法用于全量数据的 "回滚/恢复"等操作。
- redo log是innodb引擎层实现的，并不是所有引擎都有。
基于以上，binlog必不可少
问题2：那有了binlog，为啥还需要redo log呢？
- redo log是从事务开始后逐步写入磁盘的，用于故障时，恢复已提交但未及时落盘的脏页数据（落盘的步骤是先从磁盘中把相关数据页读到内存中，然后更新内存中的数据页，更新后的内存数据页属于脏页【当前内存中的数据与磁盘中不一致】，之后脏页中的数据会被写入磁盘，称为刷脏页）；而 binlog是二进制日志，只有在事务即将提交时才写入（比如在第③ 步之后突然宕机了），因此没有保存脏页数据，并没有能力在数据库崩溃后恢复完整数据页（丢失部分未写入磁盘的数据）
- 此外，数据文件的检查点是由redolog的checkPoint记录的，大致可认为checkPoint之前的数据已经刷盘了，checkPoint之后的数据还没有刷盘，所以在数据库crash之后，redolog能够知道该从什么位置进行回放redolog日志进行恢复，而binlog却做不到
基于以上，redo log也必不可少
redo log及binlog的更新流程：
① 事务中发生写操作 → ② 更新redo log buffer，并根据策略同步到redo log 文件中（redo log一阶段提交：日志内修改的记录状态分别置为prepare） → ③ 将写操作的修改结果更新到内存缓冲区（暂时还不刷入磁盘） → ④ 更新binlog buffer，并根据策略同步到binlog 文件 → ⑤ 事务commit提交（redo log二阶段提交：日志内修改的记录状态分别置为commit）→ ⑥ 最后将③中的缓冲区数据刷入数据盘
redo log buffer同步到redo log文件策略：
A. redo log 开始刷盘时机：
redo log 是事务开始后逐步写盘的。重做日志有一个缓存区 innodb_log_buffer（默认大小8M），Innodb存储引擎先将重做日志写入 innodb_log_buffer 中。
然后通过以下三种方式将innodb日志缓冲区的日志刷新到磁盘：
Master Thread 定时每秒一次执行刷新 innodb_log_buffer 到重做日志文件
每个事务 commit 时会将重做日志刷新到重做日志文件
当 redo_log_buffer 可用空间少于一半时，重做日志缓存被刷新到重做日志文件
B. redo log 释放时机：
当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的缓存空间innodb_log_buffer就可以重用（被覆盖）。
这里redo log的作用是binlog不能替代的：
意外宕机时，防止第③步中 “已修改但未被刷入进磁盘的内存缓冲区数据” ，即脏页数据丢失。即使丢失也可以通过已经写完的redo log来恢复脏页数据（内存中已修改，但未最终落盘的数据），因为写入redo log的时机是先于缓冲区数据的更新的，并且此时binlog内也还没有写入记录，所以也无法通过binlog来恢复脏页数据。
redo 日志的目的：将最终未来得及未刷新到数据盘的记录保存起来，表现为以下两点：
- 已经提交的事务（但未来得及落数据盘）对数据的修改是永久的，如：⑥中未来得及落盘
- 即使事务最终未来得及提交，这部分数据也能在重启后重新加载（重启之后系统可以通过比较日志和系统状态来决定是继续完成操作还是撤销操作）
redolog 刷盘过程：
1、binlog是server层实现的，意味着所有引擎都可以使用binlog日志
2、binlog通过追加的方式写入的，可通过配置参数max_binlog_size设置每个binlog文件的大小，当文件大小大于给定值后，日志会发生滚动，之后的日志记录到新的文件上。
3、binlog有三种记录模式，statement格式的话是记录sql语句。 row格式会记录行的内容，记两条，更新前和更新后都有。mixed：这两种方式的混合模式
binlog和redo log必须保持一致，不允许出现binlog有记录但redolog没有的情况，反之亦然。之前说过在一个事务中，redolog有prepare和commit两种状态，所以在redolog状态为prepare时记录binlog可保证两日志在commit后的记录是一致的，下图列出各种情况来说明：
现在我们再来看看整个完整的流程图
更新流程.png
流程示例：
相关参数设置建议：
1、innodb_flush_log_at_trx_commit：设置为1，表示每次事务的redolog都直接持久化到磁盘（注意这里指的是redolog日志本身落盘），保证mysql重启后数据不丢失。
2、sync_binlog： 设置为1，表示每次事务的binlog都直接持久化到磁盘（注意这里指的是binlog日志本身落盘），保证mysql重启后binlog记录是完整的。
总结：
- binlog是server层面的，redo log是引擎层面的
- binlog是二进制日志；redo log是物理日志，记录了某个数据页做了什么修改
- 应该是缓冲redo log buffer符合条件时，先从buffer落盘到redo log中，然后数据恢复时再使用redo log去做恢复
- redo log 和 binlog 有一个很大的区别就是，一个是循环写，一个是追加写。也就是说 redo log 只会记录未刷盘的日志，已经刷入磁盘的数据都会从 redo log 这个有限大小的日志文件里删除。binlog 是追加日志，保存的是全量的日志。 redo log 具有 crash-safe 的能力，而 binlog 不具备。
- redolog是在MySQL服务崩溃后用来恢复正确数据的（自动行为），binlog是“全量恢复”
3117
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
