- MySQL中的WAL, Write-Ahead-Logging, 即先写日志，后写磁盘
- MySQL执行更新语句时，InnoDb引擎会先将操作(更新)记录写到redo log中，并更新内存，此时就算更新完成了
- InnoDb引擎会在空闲或适当的时候将操作记录写到磁盘上
- InnoDb的redo log是固定大小的，从头开始写，写到末尾之后又回头开头循环写。
- 上图中画出了序号从0-3，共4个redo log
- write pos为当前写入位置， check point为检查点， write pos和check point都一直向前推进；write pos和check point之间的绿色部分就可以用来写入redo log。
- 如果redo log过多， 此时check point还没有推进， write pos就追上了check point， 那么就必须等待check point向前推进， 此时MySQL无法处理更新操作。
-
redo log提供了crash-safe的能力，即使MySQL异常重启，之前提交的记录也不会丢失。
-
redo log是InnoDb引擎特有的日志
-
binlog是MySQL Server层的日志（在笔记一中提到了，MySQL由两部分组成，引擎层和Server层）
-
这两个日志的对比
- redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
- redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
- redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
上图是MySQL InnoDb引擎执行Update语句时的流程图
-
redo log的写入分成了
prepare和commit两个阶段， 称为两阶段提交 -
利用binlog进行数据恢复的步骤
- 找到最近一次的全量备份，把这个全量备份恢复到临时库
- 找到从全量备份的时间点开始，到要恢复的时间点之间的binlog，在临时库上重放即可。
-
innodb_flush_log_at_trx_commit这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘, 建议设置成1 -
sync_binlog这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘, 建议设置成1