mysql redolog日志

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

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

那既然在执行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就可以了，可以理解为是顺序的去写磁盘，会比随机读写要好很多

在整理下思路：

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

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

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