一、上节回顾
上节我们讲到，建议将 redo log 的刷盘策略设置为1：即提交事务时，强制将 redo log buffer 里的 redo log 刷入到磁盘后才算事务提交成功。
但是我们都知道，redo log buffer 是 InnoDB 存储引擎的组件，而 MySQL 支持很多种存储引擎，那么 MySQL 在撇除存储引擎后，自己就没有记录一下关于数据更新的日志吗？
二、binlog 日志文件
redo log 本身是 InnoDB 存储引擎特有的一个东西，所以 MySQL 也提供了一种所有存储引擎共享的日志文件，叫 binlog。
所以在提交事务时，不但会有 rodo log，还有会 binlog 产生。
binlog 写入到哪里？
由于 binlog 不是 innoDB 存储引擎特有的组件，所以 binlog 不会像 redo log 一样先写入到缓冲池中的 redo log buffer 组件然后再刷回到磁盘中，所以应该是直接写入磁盘中。
binlog 的刷盘策略？
binlog 也有刷盘策略，那么就是说，binlog 并不一定是直接写入磁盘文件中。
binlog 的刷盘策略由参数 sync_binlog 参数控制。默认值是0，提交事务时，会将 binlog 写入 os cache 内存缓存中。但是这样会出现 MySQL 宕机导致内存缓存中的 binlog 丢失的问题。
所以我们建议将 sync_binlog 的值设置为1。此时当你提交事务时，会强制将 binlog 写入磁盘文件中，就不会出现上面数据丢失的情况了。
三、基于 redo log 和binlog 的事务提交
上面讲到，我们都是建议在事务提交时，强制将 redo log 和 binlog 刷入磁盘文件中，保证事务提交后，不存在日志丢失的问题。
那么，这两个日志在事务提交时的原理是怎么样的呢？
①、首先会将 rodo log buffer 中的 redo log 刷回磁盘文件中，此时磁盘文件有了对应的 redo log 日志文件；
②、接着，执行器会将 binlog 也写入到磁盘文件中，此时磁盘文件中也有了对应的 binlog 日志文件；
③、最后，还会将 binlog 日志文件的名称和位置写入到 redo log 日志文件中，同时，会在 redo log 日志文件中加上一个 commit 标记。
四、为什么有了 MySQL 的 binlog ，还有 InnoDB 的 redo log？
binlog 主要用来做数据归档的，它是逻辑日志，主要记录偏向逻辑性的日志，类似于“对表 t 中的 id=1 的一行数据进行了更新操作，更新以后的值是什么”。
redo log 主要用来做 MySQL 崩溃后数据恢复，它是物理日志，主要记录偏向物理性的日志，类似于“对哪个数据页中的哪一个记录做了什么修改”。
redo log 是 InnoDB 存储引擎特有的，而 binlog 是 MySQL Server 的组件，所以是所有存储引擎共享的。
五、为什么最后要在 redo log 中加入 commit 标记？
上面也说到 redo log 是 InnoDB 存储引擎特有的，所以它一定能被保证写入到磁盘，但是 binlog 却是 MySQL Server 的组件，所以 InnoDB 存储引擎不能保证它一定能成功写入磁盘，所以需要 rodo log 中 commit 标记来表明 binlog 写入成功了。
那为什么要保证 binlog 成功写入磁盘呢？
因为需要保证数据的一致性。
我们假设没有 commit 标记：
提交事务时，redo log 写入成功，而 binlog 写入失败，但是 InnoDB 存储引擎并不知道 binlog 是否写入成功，然后返回成功。当利用 binlog 来做数据归档时，例如 MySQL 的主从复制就是利用 binlog 来做的，那此时会因为 binlog 日志的缺失，而导致主从的数据不一致。
但是如果加入 commit 标记了，只有当 redo log 中有 commit 标记才算事务提交成功，这样就能保证两个日志文件的一致性了。