MySQL数据库之日志redolog和Binlog区别和两阶段提交问题

redo log 和 binlog 的区别：

1. redo log 它是物理日志，记录内容是“在某个数据页上做了什么修改”，属于 InnoDB 引擎。
2. binlog 是逻辑日志，记录内容是 “语句的原始逻辑”，类似于“给 id=2 的这一行的 C 字段加 1”，属于 MySQL 的 Server 层，所有存储引擎都可以用。
3. 写入的方式不一样：
   1. binlog 是追加写，写满一个文件，就创建一个新的文件继续写，不会覆盖以前的日志，保存的是全量的日志。
   2. redo log 是循环写，日志空间大小固定，全部写满就从头开始，保存未被刷入磁盘的脏页数据。
4. 用途不同
   1. binlog 用于备份恢复、主从复制
   2. redolog 用于掉电等故障恢复

如果不小心整个数据库的数据被删除了，能用 redo log 恢复吗？

不能用 redo log 文件恢复，只能用 binlog 文件恢复。

因为 redo log 文件是循环写，是会边写边擦除日志的，之记录未被刷日磁盘的数据的物理日志，已经刷入磁盘的数据都会从 redo log 文件擦除。

binlog log 文件保存的是全量的日志，也就是保存了所有的数据变更情况，理论上只要记录在 binlog 上的数据，都可以恢复，如果不小心整个数据库的数据被删除，就用 binlog 文件恢复。

两阶段提交

在执行更新语句过程，会记录redo log与binlog两块日志，以基本的事务为单位，redo log在事务执行过程中可以不断写入，而binlog只有在提交事务时才写入，所以redo log与binlog的写入时机不一样。

示例图

场景一，binlog 写入异常

那么不同的逻辑会造成什么问题？

举例，更新一条数据，update T set c = 1 where id =2

• 1. 如果 MySQL 发生异常，主库写入 binlog 失败，binlog 就没有对应的修改记录；

• 

• 2. 当进行数据恢复时，主库从 redolog 恢复数据，C=1； 那么从库读取 binlog 的数据就会出现错误，C=0，导致主从不一致。

• 

bing log 从库只读不写，主库主要写，bin log 写发生异常，那么 binlog 就没有数据，进行数据恢复的时候，主库从 redo log 恢复，从库从 binlog 恢复，就会导致主库和从库数据不一致。

由此引入两阶段提交方案来解决主从不一致问题！！！

两阶段提交：原理就是将 redo log 写入拆成两个步骤 prepare 和 commit

• 原理图

• 

场景一，写入 binlog 异常解决

当发生写入 binlog 异常时，没有对应的 binlog， 也不会有 redo log 的 commit 阶段；当 MySQL 恢复数据时，首先判断 redo log 的阶段，和是否存在 binlog，都没有，就会回滚事务。

场景二，redo log 设置 commit 发生异常

不会，虽然 redo log 处于 prepare 阶段，但是能够通过事务 id 找到对应的 binlog 日志，所以 MySQL 认为是完整的，就会提交事务恢复数据。