1. redo log
WAL: Write-Ahead Logging， 它的关键点就是先写日志，再写磁盘。
当一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log 里面，并更新内存，这个时候更新计算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面。这个往往是在比较空闲的时候做的。
write pos 是当前记录的位置，一边写一边后移。写到第3个文件末尾后就回到0号文件开头。checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。
write pos 和 checkpoint 之间的粉板上还空着的部分，可以用来记录新的操作。如果 write pos 追上 checkpoint，表示粉板满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。
有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe。
2. binlog
MySQL 整体来看，其实就有两块，一块是 Server 层，它主要做的是 MySQL 功能层面的事情；还有一块是引擎层，负责存储相关的具体事宜。
redo log 是 InndoDB 引擎特有的日志。
binlog 是 Server 层特有的日志。
binlog 有两种模式，statement 格式是记录 sql 语句， row 格式会记录行的内容，记录两条，更新前和更新后都有。
两者的不同点：
redo log 是 InndoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
redo log 是物理日志，记录的是 “在某个数据上做了什么修改”；binlog 是逻辑日志，，记录的是这个语句的原始逻辑，比如 “给 ID=2 这一行的 c 字段加 1”。
redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
3. 两阶段提交
两阶段提交写入流程：
引擎把数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，可以随时提交事务。
执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成 commit 提交状态，更新完成。
恢复数据流程：
首先，找到最近的一次全量备份，从这个备份恢复到临时库。
然后，从备份的时间点开始，将备份的 binlog 依次取出来，重放到误删表之前的那个时刻；
从临时库恢复到线上库。
如果不使用两阶段提交，那么数据库的状态有可能和用它的日志恢复出来的库的状态不一致。
4. 总结
redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，标识每次事务的 redo log 都直接持久化到磁盘。可以保证 MySQL 异常重启之后数据不丢失。
sync_binlog 参数设置成 1 的时候，标识每次事务的 binlog 都持久化到磁盘。可以保证 MySQL 异常重启之后 binlog 不丢失。
