[MySQL进阶]——事务日志1

笔记整理自 【宋红康】MySQL数据库（mysql安装/基础/高级/优化），并从《MySQL实战45讲》作为补充

事务有4种特性：原子性、一致性、隔离性和持久性。那么事务的四种特性到底是基于什么机制实现呢？

• 事务的隔离性由 锁机制 实现。 而事务的原子性、一致性和持久性由事务的 redo 日志和undo 日志来保证。
• REDO LOG 称为 重做日志 ，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持 久性。
• UNDO LOG 称为 回滚日志 ，回滚行记录到某个特定版本，用来保证事务的原子性、一致性。

redo日志

如何保证持久性？

1、思路1

在事务提交完成之前把该事务所修改的所有页面都刷新 到磁盘

缺点：

• 刷新一个完整的数据页太浪费了
• 随机10刷新起来比较慢。

2、思路2

把 修改 了哪些东西 记录一下 即可。

redo 日志本质上只是记录了一下事务对数据库进行了哪些修改

比如，某个事务将系统 表空间中 第10号 页面中偏移量为 100 处的那个字节的值 1 改成 2 。我们只需要记录一下：将第0号表 空间的10号页面的偏移量为100处的值更新为 2 。

这样在事务提交时 就会把产述内容刷新到磁盘中。即使之后系统崩溃了，重启之后只要 按照上述内容所记录的步骤重新更新一下数据页 那么该事务对数据库中所做的修改就可以被恢复出来

优点：

• redo日志降低了刷盘频率

• redo日志占用的空间非常小

• redo日志是顺序写入磁盘的

redo日志格式

• type：这条redo日志的类型。
  在MySQL 5.7.22版本中，设计InnoDB的大叔一共为redo日志设计了53种不同的类型。
• space ID：表空间ID
• page number：页号。
• data：这条redo日志的具体内容。

Mini-Transaction

以组的形式写入redo日志

保证原子性的操作时，必须以组的形式来记录 redo 日志。例如向某个索引对应的 插入一条记录的过程必须是原子的 ，不能说插了一半之后就停止了。

如何划分组？

• 一系列日志

某个需要保证原子性的操作所产生 一系 redo 日志，必须以一条类型为 MLOG_MULTl _REC_END redo 日志结尾，如图所示

只有解析到类型为 MLOG_MULTl_REC_END redo 日志时，才认为解析到了一组完整的 redo 才会进行恢复

• 一条日志

如果 type 字段的第个比特为1代表这个需要保证原子性的操作只产生了一条单一的 redo 日志

Mini-Transaction概念

把对底层页面进行一次原子访问的过程称为一个 Mini-Transaction (MTR )。一个MTR可以包含一组redo日志，在进行崩溃恢复时，需要把这一组redo日志作为一个不可分割的整体来处理。

一个事务可以包含若干条语句，每一条语句其实是由若干个 mtr 组成，每一个 mtr 又可以包含若干条 redo日志

redo日志的写入redo buffer过程

redo的组成

• 重做日志的缓冲 (redo log buffer) ，保存在内存中，是易失的

  参数设置：innodb_log_buffer_size

• 重做日志文件 (redo log file) ，保存在硬盘中，是持久的。

redo log block

为了更好地管理redo日志，把通过 MTR 生成的日志都放在了大 小为 512 字节的页（block）中。

里面包含的具体字段：

log block header中的属性：

• LOG_BLOCK_HDR NO：每一个block都有一个大于0的唯一编号，该属性就表示该编号值。
• LOG_BLOCK_HDR_DATA_LEN：表示block中已经使用了多少字节
• LOG_BLOCK_FIRST_REC_GROUP：一条redo日志也可以称为一条redo日志记录（redo log record），一个MTR会生成多条redo日志记录，这个MTR生成的这些redo日志记录被称为一个redo日志记录组（redo log record group）
• LOG_BLOCK_ CHECKPOINT_NO：表示checkpoint的序号；

log block trailer的属性：

• LOG_BLOCK_CHECKSUM：表示该block的校验值，用于正确性校验

redo 日志写入log buffer

向log buffer中写入redo日志的过程是顺序写入的。使用buf_free全局变量指明后续写入的redo日志应该写到log buffer中的哪个位置

现在假设有名为 T1、T2 的两个事务 每个事务都 包含 MTR，这几个 MTR 名字如下·

• 事务T1的两个 MTR 分别称为mtr_t1_1和mtr_t1_2

• 事务T2的两个 MTR 分别称为mtr_t2_1和mtr_t2_2

每个mtr都会产生一组redo日志，用示意图来描述一下这些mtr产生的日志情况：

不同的事务可能是 并发 执行的，所以 T1 、 T2 之间的 MTR 可能是 交替执行 的。每当 MTR 执行完成时，伴随该生成的一组日志就需要被复制到 log uffe 中。

redo log的刷盘策略

redo log的写入并不是直接写入磁盘的，InnoDB引擎会在写redo log的时候先写redo log buffer，之后以 一 定的频率 刷入到真正的redo log file 中。

注意，redo log buffer刷盘到redo log file的过程并不是真正的刷到磁盘中去，只是刷入到 文件系统缓存 （page cache）中去（这是现代操作系统为了提高文件写入效率做的一个优化），真正的写入会交给系 统自己来决定（比如page cache足够大了）。

那么对于InnoDB来说就存在一个问题，如果交给系统来同 步，同样如果系统宕机，那么数据也丢失了（虽然整个系统宕机的概率还是比较小的）。

针对这种情况，InnoDB给出 innodb_flush_log_at_trx_commit 参数，该参数控制 commit提交事务 时，如何将 redo log buffer 中的日志刷新到 redo log file 中。它支持三种策略：

• 设置为0 ：表示每次事务提交时不进行刷盘操作。（系统默认master thread每隔1s进行一次重做日 志的同步）

  

• 设置为1 ：表示每次事务提交时都将进行同步，刷盘操作（ 默认值 ）

  

• 设置为2 ：表示每次事务提交时都只把 redo log buffer 内容写入 page cache，不进行同步。由os自 己决定什么时候同步到磁盘文件。

  

redo log file

1、 相关参数设置

• innodb_log_group_home_dir ：指定 redo log 文件组所在的路径，默认值为 ./ ，表示在数据库 的数据目录下。
• innodb_log_files_in_group：指明redo log file的个数，命名方式如：ib_logfile0，iblogfile1… iblogfilen。默认2个，最大100个。
• innodb_flush_log_at_trx_commit：控制 redo log 刷新到磁盘的策略，默认为1。
• innodb_log_file_size：单个 redo log 文件设置大小，默认值为 48M 。最大值为512G，注意最大值 指的是整个 redo log 系列文件之和，即（innodb_log_files_in_group * innodb_log_file_size ）不能大 于最大值512G。

2、日志文件组

磁盘上的redo日志文件不止一个，而是以一个日志文件组 的形式出现的.这些文件以 ib_logfile[ 数字 ]" (数字可 2…) 的形式进行命名。

在将redo日志写入日志文件组时，从ib_logfile0开始写起；如果ib_logfile0写满了，就接着ib_logfile1写。如果写到最后一个文件，重新转到ib_logfile0继续写

总共的redo日志文件大小其实就是： innodb_log_file_size × innodb_log_files_in_group 。 采用循环使用的方式向redo日志文件组里写数据的话，会导致后写入的redo日志覆盖掉前边写的redo日 志？当然！所以InnoDB的设计者提出了checkpoint的概念。

3、 checkpoint

• write pos是当前记录的位置，一边写一边后移，写到文件末尾后就回到文件开头
• checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。

如果 write pos 追上 checkpoint ，表示日志文件组满了，这时候不能再写入新的 redo log记录，MySQL 得 停下来，清空一些记录，把 checkpoint 推进一下

redo的整体流程

以一个更新事务为例，redo log 流转过程，如下图所示：

第1步：先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝

第2步：生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值

第3步：当事务commit时，将redo log buffer中的内容刷新到 redo log file，对 redo log file采用追加 写的方式

第4步：定期将内存中修改的数据刷新到磁盘中

这其实就是Write-Ahead机制

Write-Ahead Log(预先日志持久化)：在持久化一个数据页之前，先将内存中相应的日志页持久化。

有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。

binlog日志

概念

MySQL整体来看，其实就有两块：一块是Server层，它主要做的是MySQL功能层面的事情；还有一块是引擎层，负责存储相关的具体事宜。

redo log是InnoDB引擎特有的日志，而Server层也有自己的日志，称为binlog（归档日志）。

redo log与binlog区别

1. redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。
2. redo log是物理日志，记录的是“在某个数据页上做了什么修改”；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1 ”。
3. redo log是循环写的，空间固定会用完；binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

整体流程分析

接下来我们对更新流程进行分析：

create table T(ID int primary key, c int);

update T set c=c+1 where ID=2;

1. 执行器先找引擎取ID=2这一行。ID是主键，引擎直接用树搜索找到这一行。如果ID=2这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
2. 执行器拿到引擎给的行数据，把这个值加上1，比如原来是N，现在就是N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
3. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态。然后告知执行器执行完成了，随时可以提交事务。
4. 执行器生成这个操作的binlog，并把binlog写入磁盘。
5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交（commit）状态，更新完成。

将redo log的写入拆成了两个步骤：prepare和commit，这就是"两阶段提交"。

为什么要有两阶段提交？

为了保证数据库的状态就有和用它的日志恢复出来的库的状态一致，简单说，redo log和binlog都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。

• 当在2之前崩溃时
  重启恢复：后发现没有commit，回滚。

  备份恢复：没有binlog 。一致

• 当在3之前崩溃
  重启恢复：虽没有commit，但满足prepare和binlog完整，所以重启后会自动commit。备份：有binlog。一致