MySQL事务日志

最新推荐文章于 2024-03-25 21:41:33 发布

原创最新推荐文章于 2024-03-25 21:41:33 发布 · 590 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#mysql #数据库

MySQL 专栏收录该内容

11 篇文章

订阅专栏

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

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

有的DBA或许会认为UNDO是REDO的逆过程，其实不然。REDO和UNDO都可以视为一种恢复操作，但是：

REDO LOG：是存储引擎层（innodb）生成的日志，记录的是物理级别上的页面修改操作，比如页号xxx、偏移量yyy，再写入了‘zzz’数据。主要为了保证数据的可靠性。
UNDO LOG ：是存储引擎层（innodb）生成的日志，记录的是逻辑操作日志，比如对某一行数据进行了INSERT语句的操作，那么UNDO LOG 就记录一条与之相反的DELETE操作。主要用于事务的回滚（UNDO LOG 记录的是每个修改操作的逆操作）和一致性非锁定读（UNDO LOG 回滚行记录到某种特定的版本 — MVCC，即多版本并发控制）。

一、REDO日志

InnoDB存储引擎是以页为单位来管理存储空间的。在真正访问页面之前，需要把在磁盘上的页缓存到内存中的Buffer Pool之后才可以访问。所有的变更都必须先更新缓冲池中的数据，然后缓冲池中的脏页会以一定的频率被刷如磁盘（checkPoint机制），通过缓冲池来优化CPU和磁盘之间的鸿沟，这样就可以保证整个的性能不会下降太快。

1.1 为什么需要REDO日志

一方面，缓冲池可以帮助我们消除CPU和磁盘之间的鸿沟，checkpoint机制可以保证数据的最终落盘，然而由于checkpoint并不是每次变更的时候就触发的，而是master线程隔一段时间去处理的。所以最坏的情况就是事务提交后，刚写完缓冲池，数据库宕机了，那么这段数据就是丢失的，无法恢复。
另一方面，事务包含持久性的特性，就是说对于一个已经提交的事务，在事务提交后即使系统发生了崩溃，这个事务对数据库中所做的更改也不能丢失。

那么如何保证这个持久性呢： 一个简单的做法，在事务提交完成之前把该事务所修改的所有页面都刷新到磁盘，但是这个简单粗暴的做法有些问题：

修改量与刷新磁盘工作量严重不成比例：
有时候仅仅修改了某个页面中的一个字节，但是我们知道在InnoDB中是以页为单位来进行磁盘IO的，也就是说我在该事务提交时不得不将一个完整的页面从内存中刷新到磁盘。一个页面默认是16KB大小，只修改一个字节就要刷新16KB的数据到磁盘上显然是小题大做了。
随机IO刷新较慢：
一个事务可能包含很多语句，即使使一条语句也可能修改许多页面，假如该事务修改的这些页面并不相邻，这就意味着在将整个事务修改的Buffer Pool中的页面刷新到磁盘时，需要进行很多的随机IO，随机IO比顺序IO更慢，尤其对于传统的机械硬盘来说。

**另一个解决思路：**我们只是想让已经提交了的事务对数据库中数据所做的修改永久生效，即使后来系统崩溃，在重启后也能把这种修改恢复出来。所以没有必要在每次事务提交时就把该事务在内存中修改过的全部页面刷新到磁盘。只需要把修改了哪些东西记录一下就好。
InnoDB引擎的事务采用了WAL技术（Write-Ahead Logging），这种技术的思想就是先写日志，再写磁盘，只有日志写入成功，才算事务提交成功，这里的日志就是REDO LOG。当发生宕机且数据未刷到磁盘的时候，可以通过REDO LOG来恢复，保证ACID中的D，这就是REDO LOG的作用。

在这里插入图片描述

1.2 REDO日志的优点即特性

1.2.1 优点

REDO日志降低了刷盘频率。
REDO日志占用的空间非常小。
存储表空间ID、页号、偏移量以及需要更新的值，所需要的存储空间是很小的，刷盘快。

1.2.2 特点

REDO日志是顺序写入磁盘的
在执行事务的过程中，每执行一条语句，就可能产生若干条redo日志，这些日志就是按照产生的顺序写入磁盘的，也就是使用顺序IO，效率比随机IO快。
事务执行过程中，REDO LOG 不断记录
REDO LOG跟BIN LOG的区别，REDO LOG是存储引擎层产生的，而BIN LOG 是数据库层产生的。假设一个事务，对表做10万行的记录插入，在这个过程中，一直不断的往REDO LOG顺序记录，而BIN LOG不会记录，直到这个事务提交，才会一次写入到BIN LOG文件中。

1.3 REDO的组成

REDO LOG 可以简单分为以下两个部分：

重做日志的缓冲（redo log buffer），保存在内存中，是易失的。
在服务器启动时就像操作系统申请一大片称之为redo log buffer的连续内存空间，翻译成中文就是redo的日志缓存区。这片内存空间被划分成若干个连续的redo log block。一个redo log block 占用 512字节的大小。

#参数设置：innodb_log_buffer_size
# redo log buffer大小，默认16M，最大值是4096M,最小值为1M
SHOW VARIABLES LIKE '%innodb_log_buffer_size%';

重做日志文件（redo log file），保存在硬盘中，是持久的
REDO日志文件ib_logfile0和ib_logfile1。

1.4 REDO LOG 的整体流程

以一个更新事务为例，redo log流转过程如下所示：
在这里插入图片描述

第一步：先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝。
第二步：生成一条重新日志并写入redo log buffer，记录的是数据被修改后的值。
第三步：当事务commit时，将redo log buffer中的内容刷新到 redo log file，对redo log file 采用追加写的方式。
第四步：定期将内存中修改的数据刷新到磁盘中。

体会： Write-Ahead log（预先日志持久化）：在持久化一个数据也之前，先将内存中相应的日志页持久化。

1.5 REDO LOG的刷盘策略

REDO LOG的写入并不是直接写入磁盘的，InnoDB引擎会在写REDO LOG的时候先写REDO LOG BUFFER，之后以一定的频率刷入到真正的 redo log file中。一定的频率即时REDO LOG的刷盘策略。
在这里插入图片描述
注意，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进行一次重做日志的同步）。

为0时，master thread 中每1秒进行一次重做日志的fsync操作，因为实例crash最多丢失1秒钟内的事务。（master thread是负责将缓冲池中的数据异步刷新到磁盘，保证数据的一致性）
数值0的话，是一种折中的做法，它的IO效率理论是高于1的，低于2的，这种策略也有丢失数据的风险，也无法保证D。

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

为1时，只要事务提交成功，redo log 记录就一定在磁盘里，不会有任何数据丢失。
如果事务执行期间MySQL挂了或宕机，这部分日志丢了，但是事务并没有提交，所以日志丢了也不会有损失。可以保证ACID的D，数据不会丢失，但是效率最差的。
建议使用默认值，虽然操作系统宕机的概率理论小于数据库宕机的概率，但是既然使用了事务，那么数据的安全相对来说要更重要些。

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

为2时，只要事务提交成功，redo log buffer中的内容只写入文件系统缓存（page cache）。
如果仅仅只是MySQL挂了不会有任何数据丢失，但是操作系统宕机可能会有1秒数据的丢失，这种情况下无法满足ACID中的D，但是数值2肯定是效率最高的。

#查看innodb_flush_log_at_trx_commit配置参数
show variables like 'innodb_flush_log_at_trx_commit';

另外，InnoDB存储引擎有一个后台线程，每隔1秒，就会把redo log buffer中的内容写到文件系统缓存（page cache），然后调用刷盘操作。
在这里插入图片描述
也就是说，一个没有提交事务的redo log记录，也可能会刷盘。因为在事务执行过程redo log 记录是会写入 redo log buffer中，这些redo log 记录会被后台线程刷盘。

在这里插入图片描述
除了后台线程每秒1次的轮询操作，还有一种情况，当redo log buffer占用的空间即将达到innodb_log_buffer_size（这个参数默认是16M）的一般的时候，后台线程会主动刷盘。

1.6 redo log file

1.6.1 相关参数设置

innodb_log_group_home_dir：指定redo log 文件主所在的路径，默认值为./，表示在数据库的数据目录下。MySQL的默认数据目录（var/lib/mysql）下默认有两个名为ib_logfile0和ib_logfile1的文件，log buffer 中的日志默认情况下就是刷新到这两个磁盘文件中。此redo日志文件位置还可以修改。
innodb_log_files_in_group：指明redo log file 的个数，命名方式如：ib_logfile0、iblogfile1…。默认2个，最大100个。
innodb_fulsh_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。

在数据库实例更新比较频繁的情况下，可以适当加大redo log 组数和大小。但也不推荐redo log设置过大，在MySQL崩溃恢复时会重新执行REDO日志中的记录。

1.6.2 日志文件组

磁盘上的redo日志文件不只一个，而是以一个日志文件组的形式出现的。这些文件以ib_logfile[数字]（数字可以是0，1，2…）的形式进行命名，每个redo日志文件大小都是一样的。
在将redo日志写入日志文件组时，是从ib_logfile0开始写，如果ib_logfile0写满了，就接着ib_logfile1写，依次类推。如果写到最后一个文件，那就重新转到ib_logfile0继续写。
在这里插入图片描述
redo日志文件的总大小：innodb_log_file_size * innodb_log_files_in_group。
采用循环使用的方式向redo日志文件组里写数据的话，会导致后写入的redo日志覆盖掉前边写的redo日志，为此InnoDB的设计者提出了checkpoint的概念。

1.6.3 checkpoint

在整个日志文件组中还有两个重要的属性，分别是write pos、checkpoint

write pos：记录当前的位置，一边写一边后移。
checkpoint：当前要擦除的位置，也是往后推移。

每次刷盘redo log记录到日志文件组中，write pos位置就会后移更新。每次MySQL加载日志文件组恢复数据时，会清空加载过的redo log记录，并把checkpoint后移更新。write pos 和 checkpoint之间的还空着的部分可以写入新的redo log记录。
在这里插入图片描述
如果write pos 追上 checkpoint ，表示日志文件组满了，这时候不能再写入新的redo log记录，MySQL得停下来，清空一些记录，把checkpoint推荐一下。

1.7 redo log 小结

InnoDB的更新操作采用的是Write Ahead log (预先日志持久化)策略，即先写日志，再写入磁盘。
在这里插入图片描述

二、UNDO 日志

redo log 是事务持久性的保证，undo log 是事务原子性的保证。在事务中更新数据的前置操作其实就是要先写入一个 undo log。

2.1 如何理解undo日志

事务需要保证原子性，也就是事务中的操作要么全部完成，要么什么也不做。但有时候事务执行到一半会出现一些情况，比如：

情况一：事务执行过程中可能遇到各种错误，比如服务器本身的错误，操作系统错误，甚至是突然断电导致的错误。
情况二：程序员可以在事务执行过程中手动输入ROLLBACK语句结束当前事务的执行。

以上情况出现，我们需要把数据改回原先的样子。这个过程称之为回滚，这样就可以造成一个假象，这个事务看起来什么都没有做，符合原子性要求。

每当要对一条记录做改动时（这里的改动可以指INSERT、DELETE、UPDATE），都需要“留一手” — 把回滚时所需的东西记录下来，比如：

当插入一条记录时，至少要把这条记录的主键值记下来，之后回滚的时候只需要把这个主键值对应的记录删掉就好了。（对于每个INSERT ，InnoDB存储引擎会完成一个DELETE）。
当删除一条记录时，至少要把这条记录中的内容都记下来，这样之后回滚时再把由这些内容组成的记录插入到表中就好了。（对于每个DELETE，InnoDB存储引擎会执行一个INSERT）。
当修改了一条记录，至少要把修改这条记录前的旧值记录下来，这样后续回滚时再把这条记录更新为旧值就可以了。（对于每个UPDATE，InnoDB存储引擎会执行一个相反的UPDATE，将修改前的行放回去）。

MySQL把这些为了回滚而记录的这些内容称之为撤销日志或者回滚日志（即undo log）。注意，由于查询操作（SELECT）并不会修改任何用户记录，所以在查询操作执行时，并不需要记录相应的undo日志。

此外，undo log 会产生redo log，也就是undo log的产生伴随着redo log的产生，这是因为undo log也需要持久性的保护。

2.2 undo日志的作用

作用1：回滚数据

用户对undo日志可能有误解：undo用于将数据库物理地恢复到执行语句或事物之前的样子。但事实并非如此，undo是逻辑日志，因此只是将数据库逻辑地恢复到原来的样子。所有的修改都被逻辑地取消了，但是数据结构和页本身在回滚之后可能大不相同。
这是因为在多用户并发系统中，可能会有数十、数百甚至数千个并发事务。数据库的主要任务就是协调对数据记录的并发访问。比如，一个事务在修改当前一个页面中某几条记录，同时还有别的事务在对同一个页中另几条记录进行修改。因此，不能将一个页回滚到事务开始的样子，因为这样会影响其他事务正在进行的工作。

作用2：MVCC

undo的另一个作用是MVCC，即在InnoDB存储引擎中MVCC的实现是通过undo来完成。当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前版本信息，以此实现非锁定读取。

2.3 undo的存储结构

2.3.1 回滚段与undo页

InnoDB对undo log的管理采用段的方式。也就是回滚端（rollback segment）。每个回滚段记录了1024个undo log segment，而在每个undo log segemt段中进行undo页的申请。

在这里插入图片描述
undo页的重用：

在这里插入图片描述

2.3.2 回滚段与事务

每个事务只会使用一个回滚段，一个回滚段在同一时刻可能会服务于多个事务。
当一个事务开始的时候，会制定一个回滚段，在事务进行的过程中，当数据被修改时，原始的数据会被复制到回滚段。
在回滚段中，事务会不断填充盘区，直到事务结束或所有的空间被用完。如果当前的盘区不够用，事务会在段中骑牛扩展下一个盘区，如果所有已分配的盘区都被用完，事务会覆盖最初的盘区或者在回滚段允许的情况下扩展新的盘区来使用。
回滚段存在于undo表空间中，在数据库中可以存在多个undo表空间，但同一时刻只能使用一个undo表空间。
当事务提交时，InnoDB存储引擎会做以下两件事情：
- 将undo log放入列表中，以供之后的purge操作。
- 判断undo log所在的页是否可以重用，若可以分配给下个事务使用。

2.3.3 回滚段中的数据分类

未提交的回滚数据（uncommitted undo information）：该数据所关联的事务并未提交，用于实现读一致性，所以该数据不能被其他事务的数据覆盖。
已经提交但未过期的回滚数据（committed undo information）：该数据关联的事务已经提交，但是仍受到undo retention参数的保持时间的影响。
事务已经提交并过期的数据（expired undo information）：事务已经提交，而且数据保存时间已经超过undo retention参数指定的时间，属于已经过期的数据。当回滚段满了之后，会优先覆盖“事务已经提交并过期的数据”。

事务提交后并不能马上删除undo log及undo log所在的页，这是因为可能还有其他事务需要通过undo log来得到行记录之前的版本。故事务提交时将undo log放入一个链表中，是否可以最终删除undo log及undo log所在页由purge线程来判断。

2.4 undo的类型

在InnoDB存储引擎中，undo log 分为：

inser undo log:
insert undo log 是指在insert操作中产生的undo log。因为insert 操作的记录，只对事务本身可见，对其他事务不可见（这是事务隔离性的要求），故该undo log 可以在事务提交后直接删除。不需要进行purge操作。
undate undo log：
undate undo log记录的是对delete和update操作产生的undo log。该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。
purge线程两个主要作用是：清理undo页和清除page里面带有Delete_Bit标识的数据行。在InnoDB中，事务中的Delete操作实际上并不是真正的删除掉数据行，而是一种Delete Mark操作。在记录上标识Delete_Bit，而不删除记录。是一种“假删除”，只是做了个标记，真正的删除工作需要后台purge线程去完成。