bin log、redo log、undo log和MVVC

logs

innodb事务日志包括redo log和undo log。redo log是重做日志,提供前滚操作,undo log是回滚日志,提供回滚操作。

undo log不是redo log的逆向过程,其实它们都算是用来恢复的日志:

redo log通常是物理日志,记录的是数据页的物理修改,而不是某一行或某几行修改成怎样怎样,它用来恢复提交后的物理数据页(恢复数据页,且只能恢复到最后一次提交的位置)。mysql中使用了大量缓存,缓存存在于内存中,修改操作时会直接修改内存,而不是立刻修改磁盘,当内存和磁盘的数据不一致时,称内存中的数据为脏页(dirty page)。为了保证数据的安全性,事务进行中时会不断的产生redo log,在事务提交时进行一次flush操作,保存到磁盘中, redo log是按照顺序写入的,磁盘的顺序读写的速度远大于随机读写。当数据库或主机失效重启时,会根据redo log进行数据的恢复,如果redo log中有事务提交,则进行事务提交修改数据。这样维护了事务的原子性、一致性和持久性。

undo log用来回滚行记录到某个版本。undo log一般是逻辑日志,根据每行记录进行记录。undo log用于数据的撤回操作,它记录了修改的反向操作,比如,插入对应删除,修改对应修改为原来的数据,通过undo log可以实现事务回滚,并且可以根据undo log回溯到某个特定的版本的数据,实现MVCC。undo log在没有活动事务依赖(用于consistent read或回滚)便可以清楚,innodb 中存在后台purge 线程进行后台轮询删除undo log。

此外还有binlog。binlog是mysql服务层产生的日志,位于innodb引擎的上层。常用来进行数据恢复、数据库复制,常见的mysql主从架构,就是采用slave同步master的binlog实现的, 另外通过解析binlog能够实现mysql到其他数据源(如ElasticSearch)的数据复制。

MVCC实现

innodb中通过B+树作为索引的数据结构,并且主键所在的索引为ClusterIndex(聚簇索引), ClusterIndex中的叶子节点中保存了对应的数据内容。一个表只能有一个主键,所以只能有一个聚簇索引,如果表没有定义主键,则选择第一个非NULL唯一索引作为聚簇索引,如果还没有则生成一个隐藏id列作为聚簇索引。

除了Cluster Index外的索引是Secondary Index(辅助索引)。辅助索引中的叶子节点保存的是聚簇索引的叶子节点的值。

InnoDB行记录中除了刚才提到的rowid外,还有trx_id和db_roll_ptr, trx_id表示最近修改的事务的id,db_roll_ptr指向undo segment中的undo log。

新增一个事务时事务id会增加,trx_id能够表示事务开始的先后顺序。

Undo log分为Insert和Update两种,delete可以看做是一种特殊的update,即在记录上修改删除标记。

update undo log记录了数据之前的数据信息,通过这些信息可以还原到之前版本的状态。

当进行插入操作时,生成的Insert undo log在事务提交后即可删除,因为其他事务不需要这个undo log。

进行删除修改操作时,会生成对应的undo log,并将当前数据记录中的db_roll_ptr指向新的undo log

参考文档

https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html#auto_id_0

https://zhuanlan.zhihu.com/p/29532524

原文地址:https://www.cnblogs.com/amunote/p/10360590.html

时间: 2024-10-10 11:06:27

bin log、redo log、undo log和MVVC的相关文章

【msql】redo and undo log

Innodb Crash Recovery InnoDB 有两块非常重要的日志,一个是undo log,另外一个是redo log,前者用来保证事务的原子性以及InnoDB的MVCC,后者用来保证事务的持久性.和大多数关系型数据库一样,InnoDB记录了对数据文件的物理更改,并保证总是日志先行,也就是所谓的WAL,即在持久化数据文件前,保证之前的redo日志已经写到磁盘 Crash Recovery是InnoDB引擎的一个特点,当故障发生,重新启服务后,会自动完成恢复操作,将数据库恢复到之前一个

MySQL的日志(二):事务日志(redo log和undo log)

本文目录:1.redo log 1.1 redo log和二进制日志的区别 1.2 redo log的基本概念 1.3 日志块(log block) 1.4 log group和redo log file 1.5 redo log的格式 1.6 日志刷盘的规则 1.7 数据页刷盘的规则及checkpoint 1.8 LSN超详细分析 1.9 InnoDB的恢复行为 1.10 和redo log相关的变量2.undo log 2.1 undo log的基本概念 2.2 undo log的存储方式

了解mysql的undo log

第一次了解mysql的时候,看到了undo log这个名词,却不知道undo log是干什么,为了能够继续看明白一些mysql的资料,不得不先弄明白undo log是什么? undo log的原理是什么?它与数据库的其它特性如何配何.这篇笔记只从原理上分析,不涉及具体的实现方法. undo log是什么? undo log是一种日志,日志中记录对于数据库的反向操作.如果把数据库的内容当做一种状态机,那么数据的写操作就是修改状态机的命令,而undo 就对应修改状态机的反向命令.所以理论上每一个对于

mysql中的事务隔离级别及可重复读读提交详细分析(mvcc多版本控制/undo log)

一.事物隔离级别 读未提交(read uncommitted)是指,一个事务还没提交时,它做的变更就能被别的事务看到.通俗理解,别人改数据的事务尚未提交,我在我的事务中也能读到. 读提交(read committed)是指,一个事务提交之后,它做的变更才会被其他事务看到.通俗理解,别人改数据的事务已经提交,我在我的事务中才能读到. 可重复读(repeatable read)是指,一个事务执行过程中看到的数据,总是跟这个事务在启动时看到的数据 是一致的.当然在可重复读隔离级别下,未提交变更对其他事

5分钟了解MySQL5.7的undo log在线收缩新特性

Part1:写在最前 在MysQL5.6版本中,可以把undo log 回滚日志分离到一个单独的表空间里:其缺点是不能回收空间大小,until MysQL5.7,but MariadDB10.1暂不支持. 本文介绍并演示MysQL5.7是如何在线收缩undo log的. undo log日志是保存在共享表空间ibdata1文件中的,随着数据库的运行时间的不断增长,ibdata1文件会越来越大,在以往的MySQL数据库版本中,如果我们想要回收ibdata1文件所占空间,会非常的复杂和困难,必须先将

InnoDB存储引擎介绍-(2)redo和undo学习

01 – Undo LogUndo Log 是为了实现事务的原子性,在MySQL数据库InnoDB存储引擎中,还用Undo Log来实现多版本并发控制(简称:MVCC). - 事务的原子性(Atomicity)事务中的所有操作,要么全部完成,要么不做任何操作,不能只做部分操作.如果在执行的过程中发生了错误,要回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过. - 原理Undo Log的原理很简单,为了满足事务的原子性,在操作任何数据之前,首先将数据备份到一个地方(这个存储数

说说MySQL中的Redo log Undo log都在干啥

阅读目录(Content) 1 undo 1.1 undo是啥 1.2 undo参数 1.3 undo空间管理 2 redo 2.1 redo是啥 2.2 redo 参数 2.3 redo 空间管理 3 undo及redo如何记录事务 3.1 Undo + Redo事务的简化过程 3.2  IO影响 3.3 恢复 在数据库系统中,既有存放数据的文件,也有存放日志的文件.日志在内存中也是有缓存Log buffer,也有磁盘文件log file,本文主要描述存放日志的文件. MySQL中的日志文件,

[转]undo log与redo log原理分析

数据库通常借助日志来实现事务,常见的有undo log.redo log,undo/redo log都能保证事务特性,这里主要是原子性和持久性,即事务相关的操作,要么全做,要么不做,并且修改的数据能得到持久化. 假设数据库在操作时,按如下约定记录日志: 1. 事务开始时,记录START T 2. 事务修改时,记录(T,x,v),说明事务T操作对象x,x的值为v 3. 事务结束时,记录COMMIT T undo log原理 undo log是把所有没有COMMIT的事务回滚到事务开始前的状态,系统

InnoDB事务日志(redo log 和 undo log)详解

数据库通常借助日志来实现事务,常见的有undo log.redo log,undo/redo log都能保证事务特性,undolog实现事务原子性,redolog实现事务的持久性. 为了最大程度避免数据写入时io瓶颈带来的性能问题,MySQL采用了这样一种缓存机制:当query修改数据库内数据时,InnoDB先将该数据从磁盘读取到内存中,修改内存中的数据拷贝,并将该修改行为持久化到磁盘上的事务日志(先写redo log buffer,再定期批量写入),而不是每次都直接将修改过的数据记录到硬盘内,