日志模块有两个redo log和binlog，redo log 是引擎层的日志（负责存储相关的事），binlog是在Server层，主要做MySQL共嗯那个层面的事情。redo log就像一个缓冲区，可以让当更新操作的时候先放redo log中，等系统不忙的时候或redo log 满了的时候再写到磁盘中，redo log的大小是固定的。·这样也可以保证，即使中途数据库重启，也可以依照redo log把未完成写入磁盘的内容完成更新。这个能力叫做crash-safe。
redo log 是InnoDB引擎特有的，而Binlog是MySQL的Server层实现的，所有引擎都可以使用。
binlog会用“追加写”的形式记录所有的逻辑操作，所以binlog文件写到一定大小会切换到下一个，并不会覆盖以前的日志。
接下来看一下执行器和InnoDB引擎在执行一个见到的update语句时的内部流程
- 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
- 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
- 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
- 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
- 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。
关于最后三步就是我们所说的两阶段提交，把redolog差写成了两个步骤：prepare和commit
两阶段提交是为了让两份日志之间的逻辑一致。
如果不是两阶段提交，无论是先写完 redo log 再写 binlog，或者采用反过来的顺序。在两个中间MySQL进程异常重启，都会发生字段的值与原库的值不同。
不只是误操作后会恢复数据，当需要扩容的时候：多搭建备库来增加系统的读能力的时候，都需要全量备份加上应用binlog实现，如果出现数据库状态“不一致”就会导致线上出现主从数据库不一致的情况。
这里借用一下别人的图，如果在两阶段中间发生了crash怎么情况？
如果时刻A的话，binlog都没写，redo log 不完整，所以直接事务回滚
如果时刻B的话，先判断binlog是否完整：一个事务的 binlog 是有完整格式的：
- statement 格式的 binlog，最后会有 COMMIT；
- row 格式的 binlog，最后会有一个 XID event。
完整了那就补充redo log，然后恢复数据，如果binlog不完整，那就事务回滚。
它们有一个共同的数据字段，叫 XID。崩溃恢复的时候，会按顺序扫描 redo log：
- 如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；
- 如果碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务。
我们可以查看binlog是否完整，却还是把redo log分为两阶段是因为redo log是在事务中的内容，如果不分两个阶段的话，完成redo log 事务就不能再回滚了，这个·时候binlog写入是啊比，InnoDB又回滚不了，数据和binlog日志就又不一致了。
redo log存储的是数据页的更新细节，binlog是更新内容。只是binlog无法实现崩溃恢复，只是redo log 没法实现归档，因为它是循环写。而且mysql系统还有很多地方都依赖于binlog
两个日志有相似的功能，也有相异的，所以两个日志都要存在，所以要想同时发挥作用，两阶段提交必不可少。
