MySQL事务日志

文章目录

  • 一、事务日志介绍
  • 二、REDO LOG
    • 1、为什么需要REDO日志?
    • 2、REDO日志的好处、特点:
    • 3、REDO日志的组成
    • 4、REDO的整体流程
    • 5、redo log的刷盘策略
    • 6、redo log file
  • 三、UNDO LOG
    • 1、为什么需要UNDO日志?
    • 2、UNDO日志的作用
    • 3、UNDO日志的存储结构
    • 4、undo log的分类
    • 5、事务日志的执行过程

一、事务日志介绍

事务有4种特性:原子性一致性隔离性持久性

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

二、REDO LOG

1、为什么需要REDO日志?

因为数据库需要REDO日志去保证事务的持久性!

那么如何去保证事务的持久性了?

简单的做法就是:在事务提交完成之前把该事务所修改的所有页面都刷新到磁盘,但是这个做法是没有必要的,每一次修改都将页面刷新到磁盘,是比较耗时间的,而且会产生事务回滚。
另一个做法,就是事务提交时才将修改的所有页面都刷新到磁盘,即使后来系统崩溃,在重启后也能把这种修改恢复出来,但是没必要每次把页面刷新到磁盘,只需要把 修改 了哪些东西 记录一下 就好,这就是REDO日志。

redo log 不是随着事务的提交才写入的,而是在事务的执行过程中,便开始写入 redo log 中。

MySQL事务日志_第1张图片

2、REDO日志的好处、特点:

好处:

  • redo日志降低了刷盘频率
  • redo日志占用的空间非常小

特点:

  • redo日志是顺序写入磁盘的
  • 事务执行过程中,redo log不断记录

3、REDO日志的组成

REDO LOG可以简单分为以下两个部分:redo log bufferredo log file

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

参数设置:innodb_log_buffer_size
redo log buffer 大小,默认 16M,最大值是4096M,最小值为1M。

mysql> show variables like '%innodb_log_buffer_size%';
+------------------------+----------+
| Variable_name     | Value  |
+------------------------+----------+
| innodb_log_buffer_size | 16777216 |
+------------------------+----------+
  • redo log file(重做日志文件):保存在硬盘中,是持久的。

4、REDO的整体流程

以一个更新事务为例,redo log 流转过程,如下图所示
MySQL事务日志_第2张图片

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

5、redo log的刷盘策略

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

这里的一定频率怎么看待呢?这就是我们要说的刷盘策略

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

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

MySQL事务日志_第3张图片

  • 设置为1 :
    表示每次事务提交时都将进行同步,刷盘操作( 默认值

MySQL事务日志_第4张图片

  • 设置为2 :
    表示每次事务提交时都只把 redo log buffer 内容写入 page cache(操作系统的缓存),不进行同步。由os自己决定什么时候同步到磁盘文件。

MySQL事务日志_第5张图片

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

6、redo log file

6.1、相关参数设置

  • innodb_log_group_home_dir :指定 redo log 文件组所在的路径,默认值为./,表示在数据库的数据目录下。MySQL的默认数据目录( var/lib/mysql )下默认有两个名为 ib_logfile0ib_logfile1 的文件,log buffer中的日志默认情况下就是刷新到这两个磁盘文件中。此redo日志文件位置还可以修改。
  • innodb_log_files_in_group(log_files文件个数):指明redo log file的个数,命名方式如:ib_logfile0,iblogfile1…iblogfilen。默认2个,最大100个。
mysql> show variables like 'innodb_log_files_in_group';
+---------------------------+-------+
| Variable_name       | Value |
+---------------------------+-------+
| innodb_log_files_in_group | 2   |
+---------------------------+-------+
#ib_logfile0
#ib_logfile1
  • innodb_flush_log_at_trx_commit:控制 redo log 刷新到磁盘的策略,默认为1。
  • innodb_log_file_size(log_files文件个数中单个大小):单个 redo log 文件设置大小,默认值为 48M 。最大值为512G,注意最大值指的是整个 redo log 系列文件之和,即(innodb_log_files_in_group ×innodb_log_file_size )不能大于最大值512G。
mysql> show variables like 'innodb_log_file_size';
+----------------------+----------+
| Variable_name    | Value  |
+----------------------+----------+
| innodb_log_file_size | 50331648 |
+----------------------+----------+

根据业务修改其大小,以便容纳较大的事务。编辑my.cnf文件并重启数据库生效,如下所示

[root@localhost ~]# vim /etc/my.cnf
innodb_log_file_size=200M

6.2、日志文件组和checkpoint

日志文件组示意图:

MySQL事务日志_第6张图片

总共的redo日志文件大小其实就是: innodb_log_file_size × innodb_log_files_in_group

采用循环使用的方式向redo日志文件组里写数据的话,会导致后写入的redo日志覆盖掉前边写的redo日志?
当然!所以InnoDB的设计者提出了checkpoint的概念。

MySQL事务日志_第7张图片

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

三、UNDO LOG

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

1、为什么需要UNDO日志?

因为数据库需要UNDO日志去保证事务的原子性!

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

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

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

undo log 用来回滚行记录到某个版本。事务未提交之前,Undo 保存了未提交之前的版本数据,Undo 中的数据可作为数据旧版本快照供其他并发事务进行快照读。是为了实现事务的原子性而出现的产物,在 MySQL innodb 存储引擎中用来实现多版本并发控制

2、UNDO日志的作用

  • 作用1:回滚数据
  • 作用2:MVCC(多版本并发控制)

3、UNDO日志的存储结构

(1)回滚段与undo页

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

  • 在 InnoDB1.1版本之前 (不包括1.1版本),只有一个rollback segment,因此支持同时在线的事务限制为 1024 。虽然对绝大多数的应用来说都已经够用。
  • 从1.1版本开始InnoDB支持最大 128个rollback segment ,故其支持同时在线的事务限制提高到了 128*1024
mysql> show variables like 'innodb_undo_logs';
+------------------+-------+
| Variable_name  | Value |
+------------------+-------+
| innodb_undo_logs | 128  |
+------------------+-------+

(2)回滚段与事务

MySQL事务日志_第8张图片

(3)回滚段中的数据分类

  • 第一类:未提交的回滚数据(uncommited undo information
  • 第二类:已经提交但未过期的回滚数据(committed undo information
  • 第三类:失误已经提交并过期的数据(expired undo information

4、undo log的分类

在InnoDB存储引擎中,undo log分为:

  • insert undo log
  • update undo log

5、事务日志的执行过程

  • 第一步:准备更新数据
  • 第二步:查看Buffer Pool中是否有对应的数据,若有,则直接跳到第三步,否则需要从磁盘中加载数据
  • 第三步:记录Undo Log
  • 第四步:执行器更新数据
  • 第五步:将更新后的数据写入Redo Log Buffer
  • 第六步:以对应的刷盘策略,将Redo Log Buffer中的数据刷新到磁盘
  • 第七步:写入BinLog到Binlog文件

MySQL事务日志_第9张图片

你可能感兴趣的:(数据库,mysql,数据库)