上一篇简单的介绍了下MVCC(多版本并发控制)的原理,MVCC会对事物内操作的数据做多版本控制,从而实现并发环境下事物对数据写操作的阻塞不影响读操作的性能。而这个多版本控制的实现是由undo log来实现的,下面的内容将会简单的介绍下undo log的内容。
mysql在事物开始操作数据之前,会先将原始数据备份到一个undo log的地方,这样做的目的有两个。第一是为了保证事物的原子性,如果事物在执行的过程中出现了某些错误,或者是用户执行了rollback的操作,mysql可以利用undo log中的备份将数据恢复到事物开始之前的状态。第二是为了实现多版本的并发控制,事物在提交之前,undo log中保存了未提交之前的数据版本,undo log可以作为旧版数据的快照供其他并发访问的事物实现快照读。
快照读:SQL读取的数据是快照版本,也就是历史版本,普通的select查询的就是快照。innodb存储引擎的快照读,读取的数据将由cache(原始数据)+undo(事物修改过的数据)两部分组成。
当前读:SQL读取的数据是最新版本,可以通过锁的机制来保证读取的数据无法被其它的事物修改。update,delete,insert,select … lock in share mode,select … for update都是当前读。
除了undo log,Mysql数据库还有一个redo log的概念,mysql在事物开始之后,事物中操作的任何数据,会将最新的数据备份到一个地方(redo log),就是在事物执行的过程中,开始将数据写入redo buffer中,最后写入redo log中,具体的落盘策略可以自行配置。这样做的目的是:为了实现事物的持久性,防止在发生故障的时间点,尚有脏页未写入磁盘,在mysql重启的时候,根据redo log重做,从而使事物未入磁盘的数据达到持久化这一特定。
说明:指定的redo log是记录在{datadir}/ib_logfile1&ib_logfile2,可以通过innodb_log_group_home_dir配置指定的目录存储。一旦事物提交成功,并且数据持久化落盘之后,redo log中的数据也就失去了意义,所以redo log中的写入是日志文件循环写入的。可以配置下列参数:
指定redo log日志文件组中的数量 innodb_log_files_in_group 默认为2
指定redo log每一个日志文件最大存储量innodb_log_file_size 默认48M
指定redo log在cache/buffer中的buffer池大小innodb_log_buffer_size 默认16M
redo log的落盘策略,即将数据从redo buffer持久化到磁盘的redo log文件中,可配置Innodb_flush_log_at_trx_commit参数,这个参数的取值有以下几种情况。
取值0,每秒提交redo buffer -> redo log os cache -> flush cache to disk,这种情况可能丢失一秒内的事物数据。
取值1,该参数的默认值,每次事物提交执行redo buffer -> redo log os cache -> flush cache to disk,这种情况可能丢失一个事物的数据,最安全,但同时性能最差。
取值2,每次事物提交执行redo buffer -> redo log os cache,在每一秒执行 -> flush cache to disk操作。
关于undo log和redo log,有下面的图可以参考。
说明:undo log和redo log可以理解为都是对数据的备份,其中undo log是对旧数据(原始数据)的备份,redo log是对新数据(事物所要提交的数据)的备份。
对数据的备份首先是会存储在各自的buffer中,即undo buffer和redo buffer,至于如何持久化到磁盘,即写入到undo log和redo log文件中,要根据设置的具体落盘策略而定。
转载:https://www.cnblogs.com/code-star/p/10693425.html