undo log&&redo log

undo log

undo log介绍

undo：意为撤销或取消，以撤销操作为目的，返回指定某个状态的操作。

undo log：数据库事务开始之前，会将要修改的记录放到undo日志中，当时事务回滚时或数据库崩溃时，可以利用undo日志，撤销未提交事务对数据库产生的影响。

undo log：产生和销毁：在事务开始前产生；事务在提交时，并不会立刻删除undolog，innodb会将该事务对应的undolog放入到删除列表中，后面会通过后台线程PURGE THRESD进行回收处理，undo log属于逻辑日志，记录一个变化过程（一条insert命令记一条delete,updata记录的也是updata更新的反向值）。

undo log存储：undo log采用段的方式管理和记录。在unnodb数据文件中包括一种rollback segment回滚段，内部包含1024个undo log segment。可以通过下面一组参数来控制undolog存储。

undo log作用

实现事务的原子性

未来实现事务的原子性而出现的产物。事务处理过程中，如果出现了错误或者用户执行了rollback语句，MySQL可以利用undolog中的备份将数据恢复到事务开始的状态。

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

undolog在innodb存储引擎中用来实现多版本并发控制。事务未提交之前，undolog保存了未提交之前的版本数据，undolog中的数据可作为数据旧版本快照供其他并发事务进行快照读。

事务A手动开启事务，执行更新操作，首先会把更新命中的数据备份到undobuffer中。

事务B手动开启事务，执行查询操作，会读取undo日志数据返回，进行快照读。

redo log

redo log 介绍

redo：顾名思义就是重做。以恢复操作为目的，在数据库发生意外时重现操作。

redolog：指在事务中修改的任何数据，将最新的数据备份存储的位置，成为重做日志。

redolog的生成和释放：随着事务操作的执行，就会生成redolog，在事务提交时会将产生redolog写入到LB，并不是随着事务的提交就立刻写入磁盘文件，等事务操作的脏页写入到磁盘后，redolog的使命也就完成了，redolog占用的空间就会重用（覆盖写入）。

redo log 工作原理

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

 修改user的数据的步骤

1、先将user的数据进行备份存储在undo中，用于后期可能的rollback。

2、随着数据的提交，把数据写入到了redo中，持久化到磁盘的redolog中，当数据库异常可以通过redolog进行恢复

为什仫不直接直接持久化到磁盘呢？？因为每次的操作都会进行一次IO频率过高，所以批量通过redo持久化进去。

redolog写入机制

redo log文件内容是以顺序循环的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。

 WP是当前记录的位置，一边写一边往后移，写到最后一个文件末尾就回到0号文件开头；

checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件；

WP和CP之间还空着的部分，可以用来记录新的操作。如果WP追上CP，表示写满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把CP推进一下。

redo log相关配置参数

每个innodb存储引擎至少有1个重做日志组（group），每个文件组至少有2个重做日志文件，默认为ib_logfile0和ib_logfile1.可以通过下面一组参数控制redolog存储：

show variables like '%innodb_log%';

redobuffer 持久化到redolog的策略，可通过innodb_flush_log_at_trx_commit设置：

0：每秒提交redobuffer-->os cache -->flush cache to disk，可能丢失一秒内的事务数据。由后台master线程每隔1秒执行一次操作。

1：（默认）每次执行事务提交执行redobuffer-->os cache -->flush cache to disk，最安全，性能最差的方式。

2：每次事务提交执行redobuffer-->os cache，然后由后台master 线程再隔每隔1秒执行os cache -->flush cache to disk操作。