文章目录
一、事务日志介绍
事务有4种特性:原子性
、一致性
、隔离性
和持久性
- 事务的
隔离性
由锁机制
实现。 REDO LOG
称为 重做日志 ,提供再写入操作,恢复提交事务修改的页操作,用来保证事务的持久性
。UNDO LOG
称为 回滚日志 ,回滚行记录到某个特定版本,用来保证事务的原子性
、一致性
。
二、REDO LOG
1、为什么需要REDO日志?
因为数据库需要REDO日志去保证事务的持久性!
那么如何去保证事务的持久性了?
简单的做法就是:在事务提交完成之前把该事务所修改的所有页面都刷新到磁盘,但是这个做法是没有必要的,每一次修改都将页面刷新到磁盘,是比较耗时间的,而且会产生事务回滚。
另一个做法,就是事务提交时才将修改的所有页面都刷新到磁盘,即使后来系统崩溃,在重启后也能把这种修改恢复出来,但是没必要每次把页面刷新到磁盘,只需要把 修改 了哪些东西 记录一下 就好,这就是REDO日志。
redo log 不是随着事务的提交才写入的,而是在事务的执行过程中,便开始写入 redo log 中。
2、REDO日志的好处、特点:
好处:
- redo日志降低了刷盘频率
- redo日志占用的空间非常小
特点:
- redo日志是顺序写入磁盘的
- 事务执行过程中,redo log不断记录
3、REDO日志的组成
REDO LOG可以简单分为以下两个部分:redo log buffer、redo 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 流转过程,如下图所示
- 第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进行一次重做日志的同步)
- 设置为1 :
表示每次事务提交时都将进行同步,刷盘操作(默认值
)
- 设置为2 :
表示每次事务提交时都只把redo log buffer
内容写入page cache
(操作系统的缓存),不进行同步。由os自己决定什么时候同步到磁盘文件。
注意,
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_logfile0
和ib_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
日志文件组示意图:
总共的redo日志文件大小其实就是: innodb_log_file_size
× innodb_log_files_in_group
。
采用循环使用的方式向redo日志文件组里写数据的话,会导致后写入的redo日志覆盖掉前边写的redo日志?
当然!所以InnoDB的设计者提出了checkpoint的概念。
如果 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)回滚段与事务
(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文件