mysql_三大日志binlog、redoLog、undoLog详解

1、说明

日志是mysql数据库的重要组成部分，记录着数据库运行期间各种状态信息。mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。作为开发，我们重点需要关注的是二进制日志(binlog)和事务日志(包括redo
log和undo log)，本文接下来会详细介绍这三种日志。

2、binlog

2.1、binlog 介绍

binlog用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。binlog是mysql的逻辑日志，并且由Server层进行记录，使用任何存储引擎的mysql数据库都会记录binlog日志。

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

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

2.2、 binlog使用场景

在实际应用中，binlog的主要使用场景有两个，分别是主从复制和数据恢复。
1）、主从复制：在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。
2）、 数据恢复：通过使用mysqlbinlog工具来恢复数据。 binlog刷盘时机
对于InnoDB存储引擎而言，只有在事务提交时才会记录biglog，此时记录还在内存中，那么biglog是什么时候刷到磁盘中的呢？mysql通过sync_binlog参数控制biglog的刷盘时机，取值范围是0-N：
0：不去强制要求，由系统自行判断何时写入磁盘； 1：每次commit的时候都要将binlog写入磁盘；
N：每N个事务，才会将binlog写入磁盘。

从上面可以看出，sync_binlog最安全的是设置是1，这也是MySQL
5.7.7之后版本的默认值。但是设置一个大一些的值可以提升数据库性能，因此实际情况下也可以将值适当调大，牺牲一定的一致性来获取更好的性能。

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和UndoLog

BinLog是MySQL Server层的日志，所有的MySQL存储引擎都支持BinLog。BinLog可以支持主从复制和数据恢复，但是对事务的ACID特性支持比较差。InnoDB存储引擎引入RedoLog和UndoLog事务日志，用于提升事务场景下的数据库性能。本文会对RedoLog和UndoLog进行介绍。

ChangeBuffer和WAL
我们以一条SQL更新语句来介绍RedoLog的作用，首先在数据库中创建user_info表，该表包含主键列id和姓名列，并向数据库中插入一列测试数据：

create table user_info
(
    id int primary key,
    name  varchar(255)
);
insert into user_info(id,name) value (1,'ls');

查询语句的执行流程 如果我们需要查询id=1的用户的信息，我们可以通过以下SQL语句进行查询：

select * from user_info where id = 1;
在这一条简单的查询语句之后，MySQL做了哪些工作呢？如下所示，MySQL执行SQL查询语句的流程包含以下步骤：

连接器：客户端和MySQL服务端建立连接，用户名密码等信息校验； 查询缓存：如果SQL语句是查询语句，则查看查询语句是否命中缓存；
分析器：对SQL语句的词法和语法进行分析，判断SQL语句的类型和对应的表等信息；
优化器：对SQL语句进行优化，选择合适的索引；
执行器：在对应的MySQL引擎上执行SQL查询语句，并返回查询结果；

更新语句的执行流程 如果我们不需要查询用户信息，而是要更新id=1的记录中的用户名为zs，则可以通过以下SQL语句进行更新：
update user_info set name=“zs” where id=1;
和上文中的查询语句类似，MySQL一样会先通过连接器建立数据库连接，然后通过分析器、优化器和执行器查找到需要更新的数据所在的行，然后更新数据。

和查询流程不一样的是，更新流程还涉及ChangeBuffer和两个重要的日志模块：BinLog和RedoLog。其中BinLog和ChangeBuffer的作用已经在前文中介绍过，BinLog用于主从复制和数据恢复，ChangeBuffer用于缓存对数据库中数据的操作，RedoLog则是本文介绍的主角了。

4、ChangeBuffer技术

对于上文中的更新语句，如果没有RedoLog，那么InnoDB引擎会按照索引查找到id=1的用户记录，把记录加载到内存中，然后修改内存中的数据事务提交后再写回磁盘。如果数据库数据更新的频率非常低，那么这样更新方式数据库也可以接受，但是在更新非常频繁的情况下，大量的离散IO会成为数据库的瓶颈，影响数据库的性能。

在更新频繁的场景下，如何降低磁盘的IO并保证事务呢？这就涉及到我们前边文章中介绍过的ChangeBuffer技术了，在满足ChangeBuffer缓存操作的条件下，InnoDB并不会立即把数据的变更操作写入磁盘，而是将这些对数据页的操作缓存到ChangeBuffer中，数据库找合适的机会再将操作Merge到数据库中。

通过ChangeBuffer技术，我们可以把对数据库的多次离散访问合并为一次数据库访问，并且用户的更新线程中不需要实际访问磁盘，大大提升了数据库性能。

5、WAL技术

不过不知道大家有没有注意到，ChangeBuffer有一个很大的问题：如果InnoDB实例在运行期间掉电，ChangeBuffer中的缓存会丢失，从而造成数据库数据的不一致，影响数据库事务的原子性和一致性。

数据库中保证事务原子性和一致性通用的方案是采用WAL（Write-ahead logging，预写式日志）技术，在使用WAL的系统中，所有的修改都先被写入到日志中，然后再被应用到系统状态中，日志通常包含redo和undo两部分信息。

RedoLog称为重做日志，每当有操作时，在数据变更之前将操作写入RedoLog，这样当发生掉电之类的情况时系统可以在重启后继续操作；
UndoLog称为撤销日志，当一些变更执行到一半无法完成时，可以根据撤销日志恢复到变更之间的状态；
MySQL的InnoDB引擎中就使用了WAL技术，所以InnoDB存储引擎包含了RedoLog和UndoLog两部分日志。

如何确保已经提交的事务不会丢失？解决这个问题比较简单，InnoDB有一个Log-Force-at-Commit机制，在事务提交的时候，和这个事务相关的RedoLog数据，包括Commit记录，都必须从LogBuffer中写入RedoLog文件，此时事务提交成功的信号才能发送给用户进程。通过这个机制，可以确保哪怕这个已经提交的事务中的部分ChangeBuffer还没有被写入数据文件，就发生了实例故障，在做实例恢复的时候，也可以通过RedoLog的信息，将不一致的数据前滚。

6、RedoLog和BinLog比较

RedoLog和BinLog不同。虽然BinLog中也记录了InnoDB表的很多操作，也能实现重做的功能，但是它们之间有很大区别。

BinLog是在存储引擎的上层产生的，不管是什么存储引擎，对数据库进行了修改都会产生二进制日志。而RedoLog是Innodb引擎层产生的，只记录该存储引擎中表的修改；
BinLog记录数据变更的逻辑性的语句，如某一行数据的的变更情况或此次变更的SQL语句。而RedoLog是在物理格式上的日志，它记录的是数据库中每个页的修改；
BinLog只在每次事务提交的时候一次性写入缓存中的日志"文件"(对于非事务表的操作，则是每次执行语句成功后就直接写入)。而RedoLog在数据准备修改前写入缓存中的RedoLog中，然后才对缓存中的数据执行修改操作；而且保证在发出事务提交指令时，先向缓存中的RedoLog写入磁盘日志，写入完成后才执行提交动作；
BinLog只在提交的时候一次性写入，所以BinLog记录方式和提交顺序有关，且一次提交对应一次记录。而RedoLog中是记录的物理页的修改，RedoLog文件中同一个事务可能多次记录，最后一个提交的事务记录会覆盖所有未提交的事务记录。例如事务T1，可能在RedoLog中记录了T1-1,T1-2,T1-3，T1共4个操作，其中T1表示最后提交时的日志记录，所以对应的数据页最终状态是T1对应的操作结果。而且RedoLog是并发写入的，不同事务之间的不同版本的记录会穿插写入到RedoLog文件中，例如可能RedoLog的记录方式如下： T1-1,T1-2,T2-1,T2-2,T2,T1-3,T1* 。
事务日志记录的是物理页的情况，它具有幂等性，因此记录日志的方式极其简练。幂等性的意思是多次操作前后状态是一样的，例如新插入一行后又删除该行，前后状态没有变化。而二进制日志记录的是所有影响数据的操作，记录的内容较多。例如插入一行记录一次，删除该行又记录一次。

7、RedoLog

7.1、详解

RedoLog包括两部分：一是内存中的日志缓冲(RedoLog Buffer)，该部分日志是易失性的；二是磁盘上的重做日志文件(RedoLog File)，该部分日志是持久的。

在概念上，Innodb通过force-log-at-commit机制实现事务的持久性，即在事务提交的时候，必须先将该事务的所有事务日志写入到磁盘上的RedoLog File和UndoLog File中进行持久化。

为了确保每次日志都能写入到事务日志文件中，在每次将RedoLog Buffer中的日志写入日志文件的过程中都会调用一次操作系统的fsync操作(即fsync()系统调用)。因为MariaDB/MySQL是工作在用户空间的，MariaDB/MySQL的RedoLog Buffer处于用户空间的内存中。要写入到磁盘上的RedoLog Buffer中，中间还要经过操作系统内核空间的操作系统缓存区，调用fsync()的作用就是将操作系统缓存区中的日志刷到磁盘上的RedoLog文件中。

RedoLog事务日志文件名为ib_logfileN，如：ib_logfile0，ib_logfile1…
RedoLog把日志从缓存写入磁盘的过程如下图所示：

MySQL支持用户自定义在事务提交时如何将日志缓存中的日志刷磁盘文件中。可以控制通过变量innodb_flush_log_at_trx_commit的值来决定。该变量有3种值：0、1、2，默认为1。但注意，这个变量只是控制事务提交时是否刷新日志缓存到磁盘。

当设置为1的时候，事务提交时会将日志缓存中的日志写入操作系统缓存，并调用fsync()持久化到磁盘文件中。这种方式即使系统崩溃也不会丢失任何数据，但是因为每次提交都写入磁盘，IO的性能较差；

当设置为0的时候，事务提交时不会将日志缓存中的日志写入操作系统缓存，而是每秒写入操作系统缓存并调用fsync()持久化到磁盘文件中。也就是说设置为0时是(大约)每秒刷新写入到磁盘中的，当系统崩溃，会丢失1秒钟的数据；

当设置为2的时候，事务提交时仅写入到操作系统缓存，然后是每秒调用fsync()将操作系统缓存中的日志持久化到磁盘文件中；

有一个变量innodb_flush_log_at_timeout的值为1秒，该变量表示的是刷日志的频率，很多人误以为是控制
innodb_flush_log_at_trx_commit值为0和2时的1秒频率，实际上并非如此。测试时将频率设置为5和设置为1，当
innodb_flush_log_at_trx_commit设置为0和2的时候性能基本都是不变的。关于这个频率是控制什么的，在后面的"刷日志到磁盘的规则"中会说。

7.2、一致性的保证

在主从复制结构中，要保证事务的持久性和一致性，需要对日志相关变量设置为如下：
如果启用了BinLog，则设置sync_binlog=1，即每提交一次事务同步写到磁盘中。
总是设置innodb_flush_log_at_trx_commit=1，即每提交一次事务都写到磁盘中。
上述两项变量的设置保证了：每次提交事务都写入二进制日志和事务日志，并在提交时将它们刷新到磁盘中。选择方式1时，由于每次事务提交都会写磁盘，在大量小事务提交的场景下会影响数据库的性能。