重做日志-redolog
是什么
innoDB存储引擎层面的日志，它的作用是当 数据更新过程中数据库发生异常导致提交的记录丢失
为什么
mysql的基本存储结构是页（记录都在页里面），所以更新语句时，mysql需要先把要更新的语句找到，加载进内存(buffer pool)，再修改对应的记录，再写会磁盘
此时就会面临问题：
1、如果内存中的数据更新了，但是未落入磁盘，mysql挂了怎么办？
2、每个请求都需要将数据立马落入磁盘，速度会很慢，mysql可能会顶不住
因此 Innodb引入了redolog
怎么做，实现原理
redolog也是需要写入磁盘的，但它是顺序写入的，顺序io比随机io快很多
目的：当我们修改了数据，写完内存了，可能还未落入磁盘，数据库挂掉了，此时可以根据redo log来恢复数据。redo log是顺序io，所以写入速度很快，记录的是物理变化(xx页做了xx修改)，文件体积小，所以恢复速度也快
- 内容：记录的是物理数据页面的修改信息（xx页做了xx修改），其redo log是顺序写入redo log fail的物理文件中去的
- 介绍一下：redolog又叫重做日志，是存储引擎层面的日志(innoDb特有的日志)，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来
- 日志大小是固定的，即写满了之后会从头开始循环写
- Innodb_log_file_size=100M(指定大小)；Innodb_log_files_in_group=5(指定个数)
归档日志-binlog
binlog（归档日志）：是mysql server层面的日志，属于逻辑日志，是以二进制形式记录的，记录的是这个语句的原始逻辑(每条变更的sql语句)，追加写的方式，即一份日志文件写到一定大小的时候会更换下一个文件，不会覆盖。
- 用于复制，在主从复制中，从库利用主库上的binlog进行传播，实现主从同步
- 用于数据库基于时间点的还原
回滚日志-undolog
undo log：在数据的修改过程中，会记录一条与当前操作相反的逻辑到undo log中，如果因为某些原因导致事务异常失败了，可以借助undo log进行回滚，保证事务的完整性
- 提供了回滚的作用，保证事务的原子性
- mvcc的实现
redolog 和bin log的区别
| bin log | redo log | |
| 实现层面 | mysql server层实现的 | innoDB存储引擎层面的 |
| 记录内容 | 记录的是逻辑日志（sql语句） | 记录的是物理日志（xx页做了xx修改） |
| 写入方式 | 追加写入，一个文件写完可以换一个文件接着写 | 循环写，空间大小固定，会覆盖 |
| 作用 | 用于主从复制，恢复数据 | 持久化 |
| 提交实际 | 事务提交时记录 | 事务开始时记录每次的变更信息 |
redolog是如何保证crash-safe的？
crash-safe是通过redo log的write ops和checkpoint机制来保证的
WAL（write ahead log）日志先行技术：先写日志，再写磁盘。对于数据更新操作，先写入redo log
redo log有两个关键的指针：write ops和checkpoint。write ops是当前记录的位置，一边写一边后移，无法移动的时候就回到开头。checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把数据更新到数据文件。write ops和checkpoint之间还空着的地方，可以用来记录新的操作，如果write ops追上了checkpoint，此时不能进行新的更新操作，需要停下来先擦除一部分内容
redolog 能保证crash-safe，还需要bin log吗？
看场景
- 主从模式下，binlog是需要的，因为从库同步主库的数据依赖于bin log
- 单机模式下，如果不考虑基于某个时间点数据的还原，可以不需要bin log。但是万一需要恢复某个时间点的数据，是做不到的，所以建议一直开启bin log
简言之，red log只有innodb有，别的存储引擎没有。redo log是循环写的，不持久保存，所以还是需要binlog。
