MySQL 学习笔记(2)-日志系统

MySQL中有2大非常重要的日志，redo log和binlog。

一、redo log和binlog是什么

• redo log 是innodb引擎特有的日志，记录的是对物理页的修改，属于物理日志。
• binlog是sever层生成的日志，独立于各个引擎存在，属于逻辑日志。

二、redo log存在的必要性

• WAL技术：Write-Ahead Logging，先写日志，再写磁盘。
• redo log可以保证数据库有crash safe的能力，因为只要redo log保存下来了，这时数据库崩溃了，那些更改的数据在内存中还没写入磁盘，当数据库重启的时候，可以通过redo log将数据库恢复至崩溃前的时间点。
• redo log是顺序写，而且可以组提交，所以写入速度相比写数据要快很多。而redo log写完之后就可以提交事务，脏数据可以在后面慢慢写盘。redo log还有buffer，加快写入速度，innodb_log_buffer_size参数就是buffer的大小。
• redo log是循环写，不归档，所以redo log不能用来恢复数据库，只用作崩溃恢复。这和oracle使用redo log完成崩溃恢复、恢复数据库、主备同步等是不一样的。因为mysql的存储引擎是插件式的，同一个数据库中可以有不同存储引擎的表，而redo log是innodb存储引擎特有的，所以恢复mysql数据库，需要一个独立于各个引擎的日志，那就是bin log。

二、binlog存在的必要性

• binlog是server层实现的，独立于各个存储引擎，是用来恢复数据库的唯一手段。
• binlog能保证crash safe吗，如果能，就不需要redo log了。

三、二阶段提交2pc

• redo log保证崩溃恢复，binlog用来恢复数据库，那他们二者如何保持一致呢。例如数据库崩溃时，redo log记录了，但是binlog没有记录，那么恢复后，数据存在，但是其他场景使用binlog恢复时，就会不一致。
• 具体是 1、redo log prepare 2、写binlog  3、commit，当在第一步完成后数据库崩溃，因为binlog没有记录，直接回滚；如果第二步完成后数据库崩溃，虽然没有commit，但是两个日志都有记录，所以事务可以认为是完整的。所以崩溃恢复时判断一个事物是提交还是回滚，主要看事务id是不是存在于binlog中。