InnoDB引擎--事务持久性

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/john_lw/article/details/80320184

事务是指构成单一逻辑工作单元的操作的集合。数据库系统维护事务的ACID四个特性:

  • 原子性:事务的所有操作在数据库中要么全部反映,要么全部不反映。
  • 一致性:事务执行前后数据库保持约束一致性和业务逻辑一致性。
  • 隔离性:在事务并发执行时,各个事务都感觉不到其他事务的存在。
  • 持久性:事务一旦提交,其更改是永久性的,即使数据库系统崩溃也能恢复。

先从持久性说起。

持久性

保证持久性的策略就是Write Ahead Logging。在事务提交之前,备份一份事务的操作日志在磁盘上,备份成功再允许事务成功提交。

InnoDB引擎中支持持久性的是redo log,redo log写入过程如图所示:
这里写图片描述

redo log的写入为顺序循环写入。默认有两个redo log文件,InnoDB顺序写其中一个,写满之后,再顺序写另外一个日志文件,再回过头来写第一个…循环往复。

既然重复利用redo log文件,就涉及到确定哪些日志可以被覆写的问题,InnoDB引擎利用CheckPoint技术来解决这个问题。

CheckPoint

深入理解InnoDB引擎–存储结构与文件中介绍了LSN记录了页的版本,CheckPoint用以表示已经刷新至磁盘的页的版本,在CheckPoint之前的事务已经持久化在磁盘上,redo log可以被覆写重用。

在事务的执行过程中,由于缓存的缘故,有些页被修改后(脏页)并没有立刻被刷新至磁盘,但是事务提交成功了(redo log已经记录完毕)。

那么什么时候刷新缓存中的脏页到磁盘呢?主要有以下三种情况:

  • 周期性刷新:Master Thread周期性刷新一定脏页到磁盘
  • 缓存不够用:基于LRU的缓存不够用,需要刷新一定脏页给新的热点页腾出位置
  • redo log不够用:checkpoint_age高出async_water_mark/sync_water_mark,刷新一定脏页到磁盘以保证redo log有足够的空间给后来事务覆写

其他问题

redo log文件大小问题

redo log 不能太大也不能太小:redo log日志太大,将会导致大量脏页驻留内存而未被刷新至磁盘,系统故障恢复时将需要更多的时间。redo log日志太小,日志文件切换频率和发生CheckPoint的频率随着升高,导致性能抖动。

redo log写入“深度”

innodb_flush_log_at_trx_commit参数控制着redo log的写入策略:

参数值 commit写入位置 性能与可靠性
0 内存里的redo log buffer,最终等待Master Thread刷新回磁盘 性能最好,可靠性最差,数据库系统故障则发生事务丢失
1 磁盘,调用fsync直接刷新至磁盘 性能最差,可靠性最好,不会发生事务丢失
2 磁盘缓存,最终等待宿主机文件系统刷新回磁盘 性能中等,可靠性中等,数据库系统故障但是宿主机操作系统不故障则不会发生事务丢失

MySQL技术内幕 InnoDB存储引擎 第2版

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页