mysql日志模块

前言

之前的文章我们讲述了mysql 的大致架构，不知道大家还有没有影响。今天我们接着上节课的内容，讲解下mysql的日志模块。

redo log日志

说起redo log日志，首先的说下，数据库操作数据的流程。数据库在插入和修改数据的时候，一般情况下是不会直接对磁盘进行操作的（为什么是一般情况下呢，因为有特殊情况，这个在后面我们会细讲，内容比较多，不放在这里讲解了）。他的操作流程是看内存理由有没有这个数据页，如果有，直接操作这个数据页。如果才会从磁盘，将该数据读到内存之中。明白这个过程的话，你就会明白，redo log日志了。redo log日志就是记录你操作数据页的日志，采用了wal（Write-Ahead Logging）技术，也就是先写日志，再写磁盘。
同时，redo log也实现了crash-safe的能力，就是你正操作数据库的时候，突然断电，或者重启，他也能保证你数据不会丢失。怎么实现的呢，很简单就是磁盘数据加载redo log就可以恢复数据了。磁盘数据是原始数据，redo log 则是记录了在原始数据上的操作。
现在数据库一般默认的存储引擎是innodb， 这里我们就介绍下innodb引擎中的redo log，在innodb中redo log 的大小是固定的，可以配置为一组n个文件。如下图，这个的是四个文件的大致样式。

wirtepos 是当前写入文件的位置，checkpos是当前要擦除文件的位置。两个都是顺时针后移的，两个指针之间的部分，就是可以写入数据的空间。

binlog 日志

binlog日志也称为归档日志，是server层的日志。redo log最初是innodb所自带的日志，在没有innodb这个插件没有集成到mysql中的时候，mysql数据库恢复数据主要靠的就是binlog 日志。
redo log 是在数据操作到磁盘之前记录的，binlog日志就是数据操作到磁盘之后记录的，为什么说binlog不支持crash-safe。因为当一个操作刚进行完，数据库异常重启了，而你的日志还没有写进去。这样就会导致数据库和日志不一致的情况出现。

binlog和redo log的区别

1.redo log 记录的是物理操作，记录的是对数据页进行了什么操作，而binlog则是逻辑日志，记录的是对这一行数据进行了什么操作。
2.binlog是server层的日志，所有的存储引擎都可以使用。redo log是innodb自带的日志，是引擎级别的日志，不是所有的引擎都有的。
3.redo 是循环写的，空间固定。binlog是追加写的方式，就是这个文件满了，可以在下一个文件接着写，

mysql提交日志的方式

mysql采用的是两段提交的方式来确保日志的一致性。如下图

为什么要这么写呢，如果不这么干，我们看看会有什么问题。
如果先提交redo log 再提交binlog，在异常重启的情况下，因为redo log是支持crash-safe的，所以操作的哪一行数据会被恢复，但是因为binlog不支持，所以binlog里没有这个记录。如果你用binlog恢复数据的话就会导致这一行数据是没操作之前的状态。
先写binlog在写redlog的话，binlog写完异常重启之后，redolog 没有这个记录就不会恢复这个记录，但是binlog有，所以binlog会恢复这条数据，但是因为redolog没有，所以这个事务是无效的，所以恢复出来就会多出来这一行记录，就会多出来一个事物，和原库的值不同（你可这个理解，你插入了一条数据c=1，但是异常重启之后，由于redo log没有写入，事务也没有，这时候你的客户端，可能受到的是操作失败，但是binlog给你恢复了，然后你再去插就会有问题，因为这个时候数据库的值和之前不一样了）。
所以两段提交，可以保证两个日志的一致性，要么一起写入，要么都没有。

总结

之前的章节，我们讲了mysql的大致架构，今天我们在昨天的基础上介绍了，mysql的日志，以及日志的存储方式，和两种日志的区别，还有就是两段提交的必要性。