Undo log

Undo log 介绍

Undo: 意为撤销或取消，以撤销操作为目的，返回指定某个状态的操作。
Undo log : 数据库事务开始之前，会将要修改的记录存放到Undo 日志里，当事务回滚或者数据库崩溃时，可以利用Undo 日志，撤销未提交事务对数据库产生的影响。
Undo log : Undo log 在事务开始前产生；事务在提交时，并不会立刻删除undo log，innodb 会将该事务对应的undo log 放入到删除列表中，后面会通过后台线程purge thread 进行回收处理。Undo Log 属于逻辑日志，记录一个变化过程。例如执行一个delete，undo log 会记录一个insert; 执行一个update，undo log 会记录一个相反的update。

Undo log 作用

实现事务的原子性

Undo Log 是为了实现事务的原子性出现的产物。事务处理过程中，如果出现了错误或者用户执行了ROLLBACK 语句，MySQL 可以利用Undo log 中的备份将数据恢复到事务开始之前的状态。

实现多版本并发控制（MVCC）

Undo log 在MySQL InnoDB 存储引擎中用来实现多版本并发控制。事务未提交之前，Undo log 保存了未提交之前的版本数据，Undo Log 中的数据可作为数据旧版快照供其他事务进行快照读。
在这里插入图片描述
事务A手动开启事务，执行更新操作，首先会把更新命中的数据备份到Undo Buffer 中。
事务B手动开启事务，执行查询操作，会读取Undo 日志数据返回，进行快照读。

Redo Log 日志

Redo Log 介绍

Redo: 顾名思义就是重做。一恢复操作作为目的，在数据库发生意外时重现操作。
Redo Log：指事务中修改的任务数据，将最新的数据备份存储的位置（Redo Log）, 被称为重做日志。
Redo Log 的生成和释放：随着事务操作的执行，就会生成Redo Log, 在事务提交时会将Redo Log 写入Log Buffer, 并不是随着事务的提交就立刻写入磁盘文件。等事务操作的脏页写入到磁盘之后，Redo Log 的使命也就完成了，Redo Log 占用的空间就可以重用（被覆盖写入）。

Redo Log 工作原理

Redo Log 是为了实现事务的持久性而出现的产物。防止在发生故障的时间点，尚有脏页未写入表的IBD文件中，在重启MySQL 服务的时候，根据Redo Log 进行重做，从而达到事务的未入磁盘数据进行持久化这一特性。
在这里插入图片描述

Redo Log 写入机制

Redo Log 文件内容是以顺序循环的方式写入文件，写满时则回溯到第一个文件，进行覆盖。
在这里插入图片描述
如图所示：

wirte pos 是当前记录的位置，以便写一边后移，写到最后一个文件末尾就回到0号文件开头；
check point 是当前要擦除的位置，也是往后推移并且循环的，擦除记录要把记录更新到数据文件。
write pos 和 check point 之间还有空的部分，可以用来记录新的操作。如果wirte pos 追上check point ，表示写满，这时候不能再执行新的更新，得停下来先擦掉一些记录，把check ponit 推荐一下。

Redo Log 相关配置参数

每个InnoDB 存储引擎至少有1个重做日志文件组（group）,每个文件组至少有2个重做日志文件，默认为ib_logfile0和ib_logfile1。可以通过下面一组参数控制Redo Log 存储。
show variables like ‘%innodb_log%’
Redo Buffer 持久化到Redo log 的策略，可通过Innodb_flush_log_at_trx_commit 设置；

0 ：每秒提交Redo buffer -> OS cache -> flush cache to diask, 可能丢失一秒内的事务数据。由后台Master 线程每隔1秒执行一次操作。
1（默认值）：每次事务提交执行Redo buffer -> OS cache -> flush cache to disk，最安全，性能最差的方式。
2：每次事务提交执行Redo Buffer -> OS cache, 然后由后台Master 线程再每隔1秒执行OS cache -> flush cache to disk 的操作。
一般建议选2，因为Mysql 挂了数据没有损失，整个服务器挂了才会损失1秒的事务提交数据。

BinLog

BinLog 记录模式

Redo Log 是属于InnoDB 引擎所特有的日志，而MySQL Server 也有自己的日志，即Binlog(二进制日志)，简称Binlog。 Binlog 是记录所有数据库表结构变更以及表数据修改的二进制日志，不会记录SELECT 和 SHOW 这类操作。Binlog 日志以事件形式记录，还包含语句执行的消耗时间。开启Binlog 日志有以下两个最重要的场景。

主从复制：在主库中开启Bin log 功能，这样主库就可以把Binlog 传递给从库，从库拿到Binlog 后实现数据恢复达到主从数据一致性。
数据恢复：通过mysqlbinlog 工具来恢复数据。

Binlog 文件名默认为"主机名——binlog-序列号"格式，例如user_binlog-0001，也可以在配置文件中指定名称。文件记录模式有statement、row和mixed 是三种。

row: 日志中会记录每一行数据被修改的情况，让后在slave 端对相同的数据进行修改。
优点：能清除记录每一行数据的修改细节，能完全实现主从数据同步和数据的恢复。
缺点：批量操作，会产出大量的日志，尤其是alter table 会让日志暴涨。
statement: 每一条被修改数据的SQL 都会记录到master 的binlog 中，slave 在复制的时候SQL 进程会解析成和原来master 端执行过的相同的SQL 再次执行。简称SQL 语句的复制。
优点：日志量小，减少磁盘IO，提升存储和恢复速度。
缺点：在某些情况下回导致主从数据不一致，比如last_insert_id()、now() 等函数。
MIXED : 以上两种模式的混合使用，一般会使用statement 模式保存binlog, 对于statement 模式无法复制的操作使用row 模式保存binlog, mysql 会根据执行的SQL 语句选择写入模式。

Binlog 文件结构

MySQL 的并log 文件中记录的是对数据库的各种修改操作，用例表示修改操作的数据结构是Log event。不同的修改操作对应不同的log event。比较常用的log event 有：query event、row event、xid event 等。
binlog 文件的内容就是各种log event 的集合。
Binlog 文件中的Log event结构如下图所示。
在这里插入图片描述

Binlog 写入机制

根据记录模式和操作触发event 事件生成event (事件触发执行机制)
将时间执行过程中产生log event 写入缓冲区，每个事物线程都有一个缓冲区
Log event 保存在一个binlog_cache_mngr 数据结构中，在该结构中有两个缓冲区，一个是stmt_cache，用于存放不支持事务的消息，另一个是trx_cache，用于存放支持事务的信息。
事务在提交结构会将生产的log event 写入到外部binlog 文件中。
不同事务以串行方式将log event 写入binlog 文件中，所以一个事务包含的log event 信息在binlog 文件中是连续的，中间不会插入其他事务的log event。binlog 是引擎插件上层的功能，事务提交第一个就会调用binlog 功能结构，然后再调用其他存储引擎的功能接口。因此先写binlog , 然后再执行innodb 的redo log/unndo log 和脏页刷新操作。