Redo log（重做日志） 和 Bin log（归档日志）

Redo log（重做日志） 和 Bin log（归档日志）

当执行一条更新语句时，MySQL是如何执行的。

以 update user set name = ‘zs’ where id = ‘00001’; 为例

1、建立连接后，分析器识别了这是一条更新SQL语句，清空缓存中有关数据

2、优化器选择索引，生成执行计划

3、执行器校验权限，从表的存储引擎中查出这条数据返回给执行器

4、执行器把这条数据name修改为zs后通过存储引擎接口更新到内存中，Innodb引擎将这条更新写到Redo log中，当前Redo log处于prepare状态,等待提交事务

5、执行器生成当前操作的Bin log写入磁盘

6、执行器调存储引擎提交事务，Redo log commit完成更新操作.

7、（系统在适当的时候把这个操作的数据写入磁盘）

Redo log 工作原理

在事务操作时，会将操作数据写入redo log. 当MySQL发生故障的时候，MYSQL在重启之后会根据redo log将未及时写入 IBD文件的数据进行重做，从而达到数据一致性。

Redo log写入机制

redo log文件采用顺序循环方式写入文件，写满后则回到第一个文件，进行覆盖写入

write pos指向当前写的位置，边写边往后移。循环写完后又从0开始

check point 指向当前擦除的位置，循环往后移动擦除，在擦除前先把记录更新到idb数据文件中

write pos 与check point 之间的位置用来写新的记录。当write pos 追上 check point。代表数据写满了。会停下来等待擦除。直到有空闲位置继续写入。

Redo Buffffer 持久化到 Redo Log 的策略，可通过 Innodb_flflush_log_at_trx_commit 设置：

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

1（默认值）：每次事务提交执行 Redo Buffffer -> OS cache -> flflush cache to disk，最安全，性能最差的方式。

2：每次事务提交执行 Redo Buffffer -> OS cache，然后由后台Master线程再每隔1秒执行OScache -> flflush cache to disk 的操作。

Bin log

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

开启Binlog日志有以下两个最重要的使用场景

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

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

bin log 有三种文件记录模式 STATEMENT、ROW和MIXED三种

ROW（row-based replication, RBR）：日志中会记录每一行数据被修改的情况，然后在

slave端对相同的数据进行修改。

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

缺点：批量操作，会产生大量的日志，尤其是alter table会让日志暴涨。

STATMENT（statement-based replication, SBR）：每一条被修改数据的SQL都会记录到

master的Binlog中，slave在复制的时候SQL进程会解析成和原来master端执行过的相同的

SQL再次执行。简称SQL语句复制。

优点：日志量小，减少磁盘IO，提升存储和恢复速度

缺点：在某些情况下会导致主从数据不一致，比如last_insert_id()、now()等函数。

MIXED（mixed-based replication, MBR）：以上两种模式的混合使用，一般会使用

STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存

binlog，MySQL会根据执行的SQL语句选择写入模式。

Binlog文件结构

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

Binlog文件中Log event结构如下图所示：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sN9zUPWr-1600947914306)(bin_log.png)]

Binlog写入机制

根据记录模式和操作触发event事件生成log event（事件触发执行机制）将事务执行过程中产生log event写入缓冲区，每个事务线程都有一个缓冲区Log Event保存在一个binlog_cache_mngr数据结构中，在该结构中有两个缓冲区，一个是stmt_cache，用于存放不支持事务的信息；另一个是trx_cache，用于存放支持事务的信息。

事务在提交阶段会将产生的log event写入到外部binlog文件中。不同事务以串行方式将log event写入binlog文件中，所以一个事务包含的log event信息在binlog文件中是连续的，中间不会插入其他事务的log event。

开启Binlog功能

需要修改my.cnf或my.ini配置文件，在[mysqld]下面增加log_bin=mysql_bin_log，重启MySQL服务。

binlog-format=ROW

log-bin=mysqlbinlog

Redo Log和Binlog区别

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

Redo Log属于物理日志，记录该数据页更新状态内容，Binlog是逻辑日志，记录更新过程。

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

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