MySQL的三种日志文件

InnoDB有三种重要的日志文件：undo log，redo log，bin log。

undo log

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

Undo Log产生和销毁：Undo Log在事务开始前产生；事务在提交时，并不会立刻删除undo log，innodb会将该事务对应的undo log放入到删除列表中，后面会通过后台线程purge thread进行回收处理。

Undo Log属于逻辑日志，记录一个变化过程。例如执行一个delete，undolog会记录一个insert;执行一个update，undolog会记录一个相反的update。

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

show variables like ‘％innodb_undo％‘

作用

• 实现事务的原子性

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

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

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

Redo log(InnoDB特有日志)

Redo Log:指事务中修改的任何数据，将最新的数据备份存储的位置（Redo Log），被称为重做日志。

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

写redo log是顺序磁盘IO，效率更高。

Redo Log工作原理

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

Redo Log 文件内容是以顺序循环的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。存在两个指针check point（检查点）、（write pos）记录点，当记录点追上检查点时，需要等待。

Bin log（MySQL Server日志）

Binlog是MySQL Server日志，记录所有数据库表结构变更以及表数据修改的二进制日志，不会记录SELECT和SHOW这类操作。Binlog日志是以事件形式记录，还包含语句所执行的消耗时间。Binlog默认关闭。开启Binlog日志有以下两个最重要的使用场景。

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

• 数据恢复：通过mysqlbinlog工具来恢复数据。

Binlog文件名默认为“主机名binlog-序列号“格式，例如oak_binlog00001，也可以在配置文件中指定名称。文件记录模式有STATEMENT、ROW和MIXED三种，具体含义如下。

• ROW（row-based replication，RBR）:日志中会记录每一行数据被修改的情况，然后在slave端对相同的数据进行修改。

  优点：记录每一行数据的修改细节，完全实现主从数据同步和数据恢复。

  缺点：批量操作会产生大量日志，例如alt table.

• STATMENT（statement–based replication，SBR）:每一条被修改数据的sQL都会记录到master的Binlog中，slave在复制的时候sQL进程会解析成和原来master端执行过的相同的SQL再次执行。简称sQL语句复制。

  优点：减少了日志量。

  缺点：SQL中会有可变字段、函数（例如now())，在一些情况下导致数据不一致。

• MIXED（mixed-based replication，MBR）:以上两种模式的混合使用，一般会使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的sQL语句选择写入模式。

Binlog文件结构

MySQL的binlog文件中记录的是对数据库的各种修改操作，用来表示修改操作的数据结构是Log event。.不同的修改操作对应的不同的Jlog event。.比较常用的log event有：Query event、.Row event、.Xid event等。binlog文件的内容就是各种Log event的集合。

写入机制

根据记录模式和操作触发event时间生成log event（事件触发执行机制）；将事务执行过程中产生的log event写入缓冲区，每个事务线程都有一个缓冲区；事务在提交阶段会将产生的log event写入到外部binlog文件中。不同的事务以串行方式执行。

使用binlog恢复数据

//按指定时间恢复
mysqlbinlog --start-datetime="2020-04-25 18:00:00" --stop-datetime="2020-04-26 00:00:00" mysqlbinlog.000002 | mysql -uroot -p1234
//按事件位置号恢复
mysqlbinlog --start-position=154 --stop-position=957 mysqlbinlog.000002 | mysql -uroot -p1234

mysqldump：定期全部备份数据库数据。mysqlbinlog可以做增量备份和恢复操作。

Redolog和Binlog区别

Redo Log是属于InnoDB引擎功能，Binlog.是属于MySQL Server自带功能，并且是以二进制文件记录。

Redo Log属于物理日志，记录该数据页更新状态内容（数据修改之后的值），Binlog是逻辑日志，记录更新过程。

Redo Log日志是循环写，日志空间大小是固定，Binlog是追加写入，写完一个写下一个，不会覆盖使用。

Redo Log作为服务器异常宕机后事务数据自动恢复使用，Binlog可以作为主从复制和数据恢复使用。Binlog没有自动crash-safe能力。