Thresh

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 文件内容是以程序循环的形式写入文件，写满时则回溯到第一个文件，进行笼罩写

write pos 是以后记录的地位，一边写一边后移，写到最初一个文件开端后就回到 0 号文件结尾；checkpoint 是以后要擦除的地位，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件；

write pos 和 checkpoint 之间还空着的局部，能够用来记录新的操作。如果 write pos 追上 checkpoint，示意写满，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推动一下。

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 disk，可能失落一秒内的事务数据。由后盾 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 秒的事务提交数据。