redo log 和 binlog 的一些总结

1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
2. redo log 是物理日志，记录的是“在某个数据页上做了什么修改，实现 crash-safe，即使数据库发生异常重启，之前提交的记录都不会丢失。而 binlog 是逻辑日志，记录的是写入性操作（不包括查询）信息，比如“给 ID=5 这一行的 c 字段加 1 ”，保证数据的一致性。
3. redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
   

4.  binlog 仅在事务提交时记录，并且对于每一个事务，仅包含对应事务的一个日志。而对于 redo log，由于其记录的是物理操作日志，因此每个事务对应多个日志条目。

 redo log 和 binlog 落盘的步骤是差不多的，都分为三部分：

1. 将日志写入 log buffer 和 binlog cache。
2. 将上述的内容写入操作系统的 file system page cache。
3. 由操作系统将文件缓存中的数据写入到磁盘中。

对数据进行修改后，需要写入 redo log 和 binlog，那么这势必存在一个先后顺序，假设执行过程中写完 redo log 日志后，binlog 日志写期间发生了异常，会发生什么？

由于 binlog 没写完就异常，这时候 binlog 里面没有对应的修改记录。从机用 binlog 日志更新数据时，就会少这次更新，而主机用 redo log 日志恢复，会导致最终数据不一致的情况。

为了解决两份日志之间的逻辑一致问题，InnoDB 使用两阶段提交方案，将 redo log 的写入拆成 prepare 和 commit 两阶段。

在数据库发生崩溃重启后，它将会去检查 redo log：

1. 如果 redo log 有 commit 标识则直接提交事务。
2. 如果 redo log 没有 commit 标识且不存在对应的完整 binlog，则回滚事务。redo log 和 binlog 有一个共同的数据字段，叫XID。崩溃恢复的时候，redo log 会拿着 XID 去 binlog 找对应的事务。
3. 如果 redo log 没有 commit 标识且存在对应的完整 binlog，说明在 commit 阶段发生了崩溃，此时实际上 redo log 和 binlog 都已经完整写入，可以提交事务。

由于 binlog 记录的是写入性操作，如果想用 binlog 来恢复数据，我们必须知道现在得从哪里开始，因为一条语句多执行几次会带来数据上的错误。但是 binlog 虽然保存了所有的历史操作，但是它没有标识每条操作是否已经写入磁盘，所以我们确定从哪开始。

而 redo log 记录的是数据页的更改，并且刷盘完成的数据会从 redo log 中删除。

References：

1. MySQL 实战 45 讲
2. MySQL各种“Buffer”之Log Buffer