一：为什么需要REDO日志
- 缓冲池可以帮助我们消除CPU和磁盘之间的鸿沟，checkpoint机制可以保证数据的最终落盘，然而由于checkpoint 并不是每次变更的时候就触发 的，而是master线程隔一段时间去处理的。所以最坏的情况就是事务提交后，刚写完缓冲池，数据库宕机了，那么这段数据就是丢失的，无法恢复。
- 事务包含持久性的特性，就是说对于一个已经提交的事务，在事务提交后即使系统发生了崩溃，这个事务对数据库中所做的更改也不能丢失。
解决思路：先写日志，再写磁盘，只有日志写入成功，才算事务提交成功，这里的日志就是rodo日志
二：什么是REDO日志
Redo Log是MySQL用于实现崩溃恢复和数据持久性的一种机制。在事务进行过程中，MySQL会将事务做了什么改动记录到Redo Log中。当系统崩溃或者发生异常情况时，MySQL会利用Redo Log中的记录信息来进行恢复操作，将事务所做的修改持久化到磁盘中。
三：redo的组成
- 重做日志的缓冲 (redo log buffer) ，保存在内存中，是易失的
- 重做日志文件 (redo log file) ，保存在硬盘中，是持久的
四：redo的整体流程
- 先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝
- 生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值
- 当事务commit时，将redo log buffer中的内容刷新到 redo log file，对 redo log file采用追加
写的方式 - 定期将内存中修改的数据刷新到磁盘中
五：redo log的刷盘策略
redo log的写入并不是直接写入磁盘的，InnoDB引擎会在写redo log的时候先写redo log buffer，之后以一定的频率刷入到真正的redo log file 中。这里的一定频率怎么看待呢？这就是我们要说的刷盘策略。
注意，redo log buffer刷盘到redo log file的过程并不是真正的刷到磁盘中去，只是刷入到 文件系统缓存中去，真正的写入会交给系统自己来决定。那么对于InnoDB来说就存在一个问题，如果交给系统来同步，同样如果系统宕机，那么数据也丢失了。
针对这种情况，InnoDB提供了一个参数，该参数控制 commit提交事务时，如何将 redo log buffer 中的日志刷新到 redo log
- 设置为0 ：表示每次事务提交时不进行刷盘操作。（系统默认master thread每隔1s进行一次重做日志的同步）
- 设置为1 ：表示每次事务提交时都将进行同步，刷盘操作（ 默认值 ）
- 设置为2 ：表示每次事务提交时都只把 redo log buffer 内容写入 page cache，不进行同步。由os自己决定什么时候同步到磁盘文件。
六：什么是Undo Log日志
Undo Log是事务原子性的保证，在事务中更新数据的前置操作其实是要先写入一个 undo log。如果事务需要回滚，则会从Undo Log中找到相应的记录来撤销事务所做的修改。另外，Undo Log还支持MVCC（多版本并发控制）机制，用于在并发事务执行时提供一定的隔离性。
七：undo log的生命周期
假设有2个数值，分别为A=1和B=2，然后将A修改为3，B修改为4
1. start transaction;
2.记录 A=1 到undo log;
3. update A = 3；
4.记录 A=3 到redo log;
5.记录 B=2 到undo log;
6. update B = 4;
7.记录B = 4 到redo log;
8.将redo log刷新到磁盘
9. commit
在1-8步骤的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响。
如果在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，因为此时redo log已经持久化。
若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数
八：什么是binlog日志？
binlog是MySQL用于记录数据库中的所有DDL语句和DML语句的一种二进制日志。它记录了所有对数据库结构和数据的修改操作，如INSERT、UPDATE和DELETE等。binlog主要用来对数据库进行数据备份和数据复制、灾难恢复等操作。
九：查看binlog日志
mysql> show binlog events [IN ‘log_name’] [FROM pos] [LIMIT [offset,] row_count];
IN 'log_name' ：指定要查询的binlog文件名（不指定就是第一个binlog文件）
FROM pos ：指定从哪个pos起始点开始查起（不指定就是从整个文件首个pos点开始算）
LIMIT [offset] ：偏移量(不指定就是0)
row_count :查询总条数（不指定就是所有行）
mysql> show binlog events in ‘atguigu-bin.000002’;
十：使用binlog日志恢复数据
mysqlbinlog恢复数据的语法如下：
mysqlbinlog [option] filename|mysql –uuser -ppass;
这个命令可以这样理解：使用mysqlbinlog命令来读取filename中的内容，然后使用mysql命令将这些内容恢复到数据库中。
filename ：是日志文件名。
option ：可选项，比较重要的两对option参数是--start-date、--stop-date 和 --start-position、--
stop-position。
--start-date 和 --stop-date ：可以指定恢复数据库的起始时间点和结束时间点。
--start-position和--stop-position ：可以指定恢复数据的开始位置和结束位置
面试题：
1. redolog和undolog区别?
（1）redo log：记录的是"物理级别"上的页修改操作，比如页号xx、偏移量yyy，写了’zzz’数据
undo log：记录的是逻辑操作，比如对某一行数据进行了INSERT语句操作，那么 undo log就记录一条与之相反的DELETE操作
（2）redo log：目的是为了保证事务的持久性，主要用于崩溃恢复
undo log：目的是为了保证事务的原子性和一致性，主要用于事务回滚
2. binlog、redolog和undolog区别?
（1）redo log和undo log主要用于事务管理，redolog用来做恢复，undolog用来做回滚
binlog主要用来对数据库进行数据备份和数据复制、崩溃恢复等操作
（2）redo log和undo log在存储引擎层产生的，而binlog则是数据库层产生的
3. MySQL的binlog有几种格式?
binlog的格式分为基于语句的格式和基于行的格式。MySQL的bin log主要支持三种格式，分别是statement、row以及mixed
（1）statement：binlog 里面记录的就是 SQL 语句的原文，也就是数据库中执行的SQL会原封不动的记录到binlog中。
缺点：会导致主从同步的数据不一致问题。比如说，当我们使用DELETE或者UPDATE的时候，指定了LIMIT，但是并没有使用order by，那么最终这条语句在主库和从库上的执行结果可能是不一样的
（2）row：不记录每条sql语句的上下文信息，仅记录哪条数据被修改了，修改成什么样了。
缺点：可能会要记录更多的内容，所以，带来的问题就是基于这种格式的binlog，在数据恢复的时候，会需要更长的时间，也会导致磁盘IO和网络IO都比较高
（3）mixed：实际上就是Statement与Row的结合
4. 什么是事务的2阶段提交？
所谓事务的2阶段提交，其实是在更新过程中，保证binlog和redolog—致性的一种手段，他的过程是：
（1）Prepare 阶段：这个阶段 SQL 已经成功执行并生成 redolog，处于prepare阶段
（2）BinLog持久化：binlog 提交，通过 write(）将 binlog 内存日志数据写入文件缓冲区，通过 sync()将 binlog 从文件缓冲区永久写入磁盘；
（3） Commit：在执行引擎内部执行事务操作，更新redolog，处于Commit阶段。
例子：假设先写入redo log 成功，但是没来得及写入bin log ，系统崩了。在MySQL重启后，可以根据redolog把记录更新成功，但是binlog由于没写成功，也就意味着，主备同步的时候，是缺了一条SQL的，导致主备库之间数据不一致，所以引入二阶段提交。
