mysql redolog日志

在mysql的架构中，有几个比较重要的日志，分别是binlog、redolog和undoLog，这篇博客主要记录redo log

是什么

redo log我们称之为重做日志，mysql通过redo log日志来保证了持久性；
mysql事务要求要保证持久性，其实如果不考虑性能因素，要保证持久性，最简单的做法，就是：在事务提交的时候，将更新、或者删除的数据，同步去更新磁盘上的数据页即可
但是这样做，有一个很大的问题，就是性能问题，因为mysql在磁盘上存储的时候，是按照数据页来存储的，提交的一个sql有可能要更新好几个数据页的数据，这几个数据页有可能不是连续的，那这时候，就是随机读写，随机读写磁盘是非常耗时的，根本扛不住高并发

redo log怎么保证数据持久性

那既然在执行update语句的时候，实时去更新磁盘上的数据不行，那mysql设计的时候，有一个buffer pool的概念，可以理解为：我们在执行一个update、delete、insert的时候，都是先写到内存中的这个buffer pool中，然后返回给客户端成功，mysql内部会通过异步线程去写磁盘
这种方式虽然性能比较好，但是会有丢失数据的可能，所以，此时就有了redo log这个东西

redolog日志有两部分，一部分是在内存中的，我们称之为redo log buffer，一部分是在磁盘上的，我们称之为redo log file；也就是说，redo log buffer中的数据，也是要写到redo log file中，此时在往磁盘上写数据的时候，就可以直接append就可以了，可以理解为是顺序的去写磁盘，会比随机读写要好很多

在整理下思路：

1. 在执行sql的时候，MySQL会先把数据更新到buffer pool中，此时，对于客户端，我们可以认为已经执行成功了
2. 同时，会把相关信息写入到redo log buffer中，此时也是在内存中
3. 在执行commit操作的时候，会将redo log buffer中的数据写入到redo log file中
4. 同时，binlog在写入磁盘成功之后，会写一个标记到redo log file中，这是为了保证两者的数据是一致的
5. 到这里，才认为事务提交成功；所以我们可以认为：在事务提交的时候，我们真正update的数据，在buffer pool中，redolog File文件中
6. 在底层，会通过io线程，把buffer pool中的数据更新到磁盘上的数据页

所以，整体来看，我觉得，为了避免update的时候，去实时更新磁盘数据，引入了redo log这个东西，只是说，在事务提交之前，会通过顺序写磁盘的形式，将update的信息写入到redo log file中，这样，可以保证mysql更新的性能，同时，保证了数据的可靠性和持久性
也就是说：即使为在update了之后，数据还没真正的写入到磁盘上，这时候，主机宕机了，那我也可以通过binlog和redo log来恢复没有持久化的数据

redo log 刷盘时机

redo log 在从内存中持久化到redo log file的时候，也是有策略的，会有相应的配置，来设置持久化的时机

innodb_flush_log_at_trx_commit

这个参数，就是控制redo log 从内存中，写入到磁盘中的时机
如果为0：提交事务时，不会强制将数据从内存写入到磁盘中，而是每隔1S，将数据从内存中，写入到os cache中，并通过fsync()命令刷入到磁盘中
如果为1：表示实时同步，在提交事务的时候，会将redo log buffer中的数据写入到os cache，并调用fsync()写入到磁盘中
如果为2：表示实时写，延迟刷；每次提交事务，都会将数据从redo log buffer写入到os cache中，但是会每隔1S，调用fsync()，将数据持久化到磁盘上