MySQL三大日志——binlog、redoLog、undoLog详解

目录跳转电梯

• 1. redoLog
  • 1.1 为什么需要redo log
  • 1.2 redo log基本概念
  • 1.3 redo log记录形式
• 2. binlog
  • 2.1 binlog基本概念
  • 2.2 binlog使用场景
  • 2.3 binlog日志格式
• 3. redolog和binlog区别
• 4. undo log

日志是mysql数据库的重要组成部分，记录着数据库运行期间各种状态信息，能帮助我们进行很多容错及分析工作，其中有三大日志与我们这些开发者息息相关，本文将介绍binlog、redoLog、undoLog三种日志：

1. redoLog

1.1 为什么需要redo log

我们都知道，事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。

事务在运行过程中，都是在内存的Buffer Pool修改页面，事务提交后，这些被修改后的脏页并不会立刻刷盘（立刻刷盘开销太大，一方面是一个页面可能就修改了一点点，将整个页面刷盘不值当，另一方面是一个事务会涉及不同的页面，如果将这些页面都刷盘会产生很多的随机IO）。 但如果不采取其他措施，那么在事务提交后MySQL发生故障，导致内存中数据丢失，那么这个已提交事务作出的更改也会丢失，那么mysql是如何保证内存和磁盘的一致性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面： 1）、 因为Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了！ 2）、 一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差！

所以这里就需要引入redo日志，对任意页面进行修改的操作都会生成redo日志，在事务提交时，只要保证生成的redo日志成功落盘即可，这样，即使MySQL发生故障导致内存中的数据丢失，也可以根据已落盘的redo日志恢复数据

1.2 redo log基本概念

redo log是InnoDB存储引擎层的日志，又称重做日志文件，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。一个事务生成的redo日志是按顺序写入磁盘的，是顺序IO，在实例和介质失败（media failure）时，redo log文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用redo log恢复到掉电前的时刻，以此来保证数据的完整性。

redo log包括两部分：一个是内存中的日志缓冲(redo log buffer)，另一个是磁盘上的日志文件(redo log file)。mysql每执行一条DML语句，先将记录写入redo log buffer，后续某个时间点再一次性将多个操作记录写到redo log file。这种先写日志，再写磁盘的技术就是MySQL里经常说到的WAL(Write-Ahead Logging) 技术。

1.3 redo log记录形式

redo log日志的大小是固定的，即记录满了以后就从头循环写。 redolog记录方式：

简单的redo日志——记录哪个表空间中的哪个页面从哪个位置开始的多少个节点要修改成什么

复杂的redo日志——记录了对哪个表空间的哪个页面进行修改，存储了对该页面进行修改操作的一些必备要素，重启时，MySQL会根据redo日志的类型，将redo日志中的必备要素作为参数，调用日志类型对应的函数，恢复数据

在计算机操作系统中，用户空间(user space)下的缓冲区数据一般情况下是无法直接写入磁盘的，中间必须经过操作系统内核空间(kernel space)缓冲区(OS Buffer)。因此，redo log buffer写入redo log file实际上是先写入OS Buffer，然后再通过系统调用fsync()将其刷到redo log file中，过程如下：

在这里插入图片描述

mysql支持三种将redo log buffer写入redo log file的时机，可以通过innodb_flush_log_at_trx_commit参数配置，各参数值含义如下：

在这里插入图片描述

redo log实际上记录数据页的变更，而这种变更记录是没必要全部保存，因此redo log实现上采用了大小固定，循环写入的方式，当写到结尾时，会回到开头循环写日志。

在这里插入图片描述

总结：确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。 还想继续深入的同学可以看看这篇文章 无比详细的redolog讲解

2. binlog

2.1 binlog基本概念

binlog是属于MySQL Server层面的，又称为归档日志，属于逻辑日志，是以二进制的形式记录的，用于记录数据库执行的写入性操作(不包括查询)信息，依靠binlog是没有crash-safe能力的

啥是逻辑日志啥是物理日志： 逻辑日志：可以简单理解为记录的就是sql语句 物理日志：因为mysql数据最终是保存在数据页中的，物理日志记录的就是数据页变更

另外，binlog是通过追加的方式进行写入的，可以通过max_binlog_size参数设置每个binlog文件的大小，当文件大小达到给定值之后，会生成新的文件来保存日志。

2.2 binlog使用场景

在实际应用中，binlog的主要使用场景有两个，分别是主从复制和数据恢复。 1）、主从复制：在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。 2）、 数据恢复：通过使用mysqlbinlog工具来恢复数据。

2.3 binlog日志格式

binlog日志有三种格式，分别为STATMENT、ROW和MIXED。

在 MySQL 5.7.7之前，默认的格式是STATEMENT，MySQL 5.7.7之后，默认值是ROW。日志格式通过binlog-format指定。

STATMENT 基于SQL语句的复制(statement-based replication, SBR)，每一条会修改数据的sql语句会记录到binlog中。 优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO, 从而提高了性能； 缺点：在某些情况下会导致主从数据不一致，比如执行sysdate()、slepp()等。 ROW 基于行的复制(row-based replication, RBR)，不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了。 优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题； 缺点：会产生大量的日志，尤其是alter table的时候会让日志暴涨 MIXED 基于STATMENT和ROW两种模式的混合复制(mixed-based replication, MBR)，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog

3. redolog和binlog区别

redo log是属于innoDB层面，binlog属于MySQL Server层面的，这样在数据库用别的存储引擎时可以达到一致性的要求。 redo log是物理日志，记录该数据页更新的内容；binlog是逻辑日志，记录的是这个更新语句的原始逻辑 redo log是循环写，日志空间大小固定；binlog是追加写，是指一份写到一定大小的时候会更换下一个文件，不会覆盖。 binlog可以作为恢复数据使用，主从复制搭建，redo log作为异常宕机或者介质故障后的数据恢复使用。

redo log是InnoDB存储引擎层的日志，binlog是MySQL Server层记录的日志， 两者都是记录了某些操作的日志(不是所有)自然有些重复（但两者记录的格式不同）。

4. undo log

数据库事务四大特性中有一个是原子性，具体来说就是 原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。

实际上，原子性底层就是通过undo log实现的。

undo log主要记录了数据的逻辑变化，比如一条INSERT语句，对应一条DELETE的undo log，对于每个UPDATE语句，对应一条相反的UPDATE的undo log，这样在发生错误时，就能回滚到事务之前的数据状态。

undo log保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读