代码驿站移动版

当前位置：主页 > 数据库 > Mysql >

MySQL系列之redo log、undo log和binlog详解

时间：2022-04-02 14:27:47 | 栏目：Mysql | 点击：次

事务的实现

redo log保证事务的持久性，undo log用来帮助事务回滚及MVCC的功能。

InnoDB存储引擎体系结构

redo log

Write Ahead Log策略

事务提交时，先写重做日志再修改页；当由于发生宕机而导致数据丢失时，就可以通过重做日志来完成数据的恢复。

重做日志文件： 在默认情况，InnoDB存储引擎的数据目录下会有两个名为ib_logfile1和ib_logfile2的文件。每个InnoDB存储引擎至少有1个重做日志文件组(group)，每个文件组下至少有2个重做日志文件。

下面图一，很好说明重做日志组以循环写入方式运行，InnoDB存储引擎先写ib_logfile1，当达到文件最后时，会切换至重做日志文件ib_logfile2.

而图2，增加一个OS Buffer，有助于理解fsync过程。

关于log group，称为重做日志组，是一个逻辑上的概念。InnoDB存储引擎实际只有一个log group。

log group中第一个redo log file，其前2KB部分保存4个512字节大小块：

重做日志缓冲刷新到磁盘

下面三种情况刷新：

补充上述三种情况第二种，触发写磁盘过程由参数innodb_flush_log_at_trx_commit控制，表示提交(commit)操作时，处理重做日志的方式。

参数innodb_flush_log_at_trx_commit有效值有0、1、2

0，当数据库发生宕机时，部分日志未刷新到磁盘，因此会丢失最后一段时间的事务。
2，当操作系统宕机时，重启数据库后会丢失未从文件系统缓存刷新到重做日志文件那部分事务。

下图有助于理解

重做日志块

在InnoDB存储引擎中，重做日志都是以512字节进行存储的。意味着重做日志缓存、重做日志文件都是以块(block)的方式进行保存的，每块512字节。

重做日志头12字节，重做日志尾8字节，故每个重做日志块实际可以存储492字节。

重做日志格式

redo log是基于页的格式来记录的。默认情况下，innodb的页大小是16KB(由 innodb_page_size变量控制)，一个页内可以存放非常多的log block(每个512字节)，而log block中记录的又是数据页的变化。

log body的格式分为4部分：

如下图，分别是insert和delete大致的记录方式。

redo日志恢复

下面LSN(Log Sequence Number)代表checkpoint，当数据库在LSN为10000时发生宕机，恢复操作仅恢复LSN10000-LSN13000范围内日志

undo log

undo log的作用

undo是逻辑日志，只是将数据库逻辑地恢复到原来的样子；所有修改都被逻辑地取消了，但是数据结构和页本身在回滚之后可能不大相同。

undo log有两个作用：提供回滚和多个行版本控制(MVCC)。

InnoDB存储引擎回滚时，对于每个INSERT，会完成一个DELETE；对于每个DELETE，会执行一个INSERT；对于每个UPDATE，会执行一个相反的UPDATE，将修改前的行放回去。

MVCC： 当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取。

undo log的存储方式

innodb存储引擎对undo的管理采用段的方式。rollback segment称为回滚段，每个回滚段中有1024个undo log segment。

在以前老版本，只支持1个rollback segment，这样就只能记录1024个undo log segment。后来MySQL5.5可以支持128个rollback segment，即支持128*1024个undo操作，还可以通过变量 innodb_undo_logs (5.6版本以前该变量是 innodb_rollback_segments )自定义多少个rollback segment，默认值为128。

undo log默认存放在共享表空间中。

事务提交undo log处理过程

当事务提交时，InnoDB存储引擎会做以下两件事：

当事务提交时，首先将undo log放入链表中，然后判断undo页的使用空间是否小于3/4，若是，则表示该undo页可以被重用，之后新的undo log记录在当前undo log的后面

undo log分为：

因为事务隔离性，insert undo log对其他事务不可见，所以该undo log可以在事务提交后直接删除，不需要进行purge操作。

update undo log记录的是对delete和update操作产生的undo log。该undo log可能需要提供MVCC机制，因此不能提交时就进行删除

update分为两种情况：

InnoDB purge时，会先从history列表找undo log，然后再从undo page中找undo log；可以避免大量随机读取操作，从而提高purge效率。

MVCC(多版本并发控制)

MVCC其实就是在每一行记录后面增加两个隐藏列，记录创建版本号和删除版本号，而每一个事务在启动的时候，都有一个唯一的递增的版本号。

MVCC只在REPEATABLE READ 和READ COMMITTED两个隔离级别下工作。读未提交不存在版本问题，序列化则对所有读取行加锁。

示例：

插入操作：记录的创建版本号就是事务版本号

如插入一条记录，事务id假设是1，则创建版本号也是1

id name create version delete version
1 test 1

更新操作：先标记旧版本号为已删除，版本号就是当前版本号，再插入一条新的记录

如事务2把name字段更新
update table set name = 'new test' where id = 1;

原来的记录被标记删除，删除版本号为2，并插入新记录，创建版本号为2
id name create version delete version
1 test 1 2
1 new test 2


删除操作：把事务版本作为删除版本号

如事务3把记录删除
delete from table where id = 1;

id name create version delete version
1 test 2 3

查询操作

需满足以下两个条件的记录才能被事务查询出来：

MVCC好处：减少锁的争用，提升性能

binlog

二进制文件概念及作用

二进制文件(binary log)记录了对MySQL数据库执行更改的所有操作(不包含SELECT、SHOW等，因为对数据没有修改)

二进制文件主要几种作用：

二进制文件三个格式

MySQL 5.1开始引入binlog_format参数，该参数可设值有STATEMENT、ROW和MIX

redo log和二进制文件区别

(二进制文件用来进行POINT-IN-TIME(PIT))的恢复及主从复制环境的建立。

group commit

若事务为非只读事务，则每次事务提交时需要进行一次fsync操作，以此保证重做日志都已经写入磁盘。但磁盘fsync性能有限，为提高磁盘fsync效率，当前数据库都提供group commit功能，即一次可以刷新确保多个事务日志被写入文件。

对InnoDB group commit，进行两阶段操作：

InnoDB1.2前，开启二进制文件，group commit功能失效问题：

开启二进制文件后，其步骤如下：
1）当事务提交时，InnoDB存储引擎进行prepare操作
2）MySQL数据库上层写入二进制文件
3）InnoDB将日志写入重做日志文件

a）修改内存中事务对应的信息，并将日志写入重做日志缓冲b）调用fsync将确保日志都从重做日志缓冲写入磁盘

其中在保证MySQL数据库上层二进制文件的写入顺序，和InnoDB事务提交顺序一致，MySQL内部使用了prepare_commit_mutex锁，从而步骤3）中a）步不可以在其他事务执行步骤b）时进行，从而导致roup commit功能失效。

解决方案便是BLGC(Binary Log Group Commit)

MySQL 5.6 BLGC实现方式分为三个阶段：

您可能感兴趣的文章:

相关文章