redolog和binlog区别
- redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
- redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑。
- redo log 是循环写的，空间固定会用完（4个文件，每个文件1Ｇ）；binlog 是可以追加写入的。“追加写”是指 binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
- binlog 日志没有 crash-safe 的能力，只能用于归档。而 redo log 来实现 crash-safe 能力。
- redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。
crash-safe
CrashSafe指MySQL服务器宕机重启后，能够保证：
- 所有已经提交的事务的数据仍然存在。
- 所有没有提交的事务的数据自动回滚。
如果MySQL宕机了，重启后，就需要检查redolog 日志文件里面，系统会自动定位到上次checkpoint的位置，同时，每个数据页中也存在一个LSN，当redo log中的LSN大于数据页中的LSN时，说明重启前redo log中的数据未完全写入数据页中，那么将从数据页中记录的LSN开始，从redo log中恢复数据。
比如redolog 的LSN 是 13000，数据库页的LSN是 10000，那么说明重启前有部分数据未完全刷入到磁盘的数据页中，那么系统将会恢复redo log 中LSN从10000开始到13000的记录到数据页中。把未同步到MySQL的数据同步到磁盘，保证宕机之前的事物数据存到MySQL中去
两段提交
为了保证binlog 和 redolog两份日志最终恢复到数据库的数据是一致的，采用两阶段提交的机制。
例如现在有一个数据更新的sql
update T set c=c+1 where ID=2;
- 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器;否则，需要先从磁盘读入内 存，然后再返回。
- 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的 一行数据，再调用引擎接口写入这行新数据。
- 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
- 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
- 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交(commit)状 态，更新完成。
两段提交的必要性
假设redo log和binlog分别提交，可能会造成用日志恢复出来的数据和原来数据不一致的情况。
- 情况一： 先写redolog再写binlog 如果在一条语句redolog之后崩溃了，binlog则没有记录这条语句。系统在用binlog恢复从库时便会少了这一次的修改。恢复的从库少了这条更新。
- 情况二：先写binlog再写redolog 如果在一条语句binlog之后崩溃了，redolog则没有记录这条语句（可以理解为主库没有）。系统在用binlog恢复从库时便会多了这一次的修改。恢复的从库多了这条更新。
由此可见，如果不使用两阶段提交，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。
两段提交崩溃恢复
采用两阶段提交，在做崩溃恢复(Crash recovery)时分为以下3种情况:
- 情况一： binlog无记录，redolog状态prepare 由于 binlog 还没写，redo log 处于 prepare 状态还没提交，所以崩溃恢复的时候，这个事务会回滚，此时 binlog 还没写，所以也不会传到备库。
- 情况二：binlog有记录，redolog状态prepare redolog 中的日志是不完整的，处于 prepare 状态，还没有提交，那么恢复的时候，首先检查 binlog 中的事务是否存在并且完整，如果存在且完整，则直接提交事务，如果不存在或者不完整，则回滚事务。
- 情况三：binlog有记录，redolog状态commit 直接提交事务，不需要恢复。
