Undo:意为撤销或取消,以撤销操作为目的,返回某个状态的操作。
站在用户的角度思考问题,与客户深入沟通,找到故城网站设计与故城网站推广的解决方案,凭借多年的经验,让设计与互联网技术结合,创造个性化、用户体验好的作品,建站类型包括:成都网站设计、网站制作、企业官网、英文网站、手机端网站、网站推广、域名与空间、雅安服务器托管、企业邮箱。业务覆盖故城地区。
Undo Log:数据库事务开始之前,会将要修改的记录放到Undo日志里,当事务回滚时或者数据库崩溃时,可以利用UndoLog撤销未提交事务对数据库产生的影响。
Undo Log是事务原子性的保证。在事务中更新数据的前置操作其实是要先写入一个Undo Log
事务需要保证原子性,也就是事务中的操作要么全部完成,要么什么也不做。但有时候事务执行到一半会出现一些情况,比如:
每当我们要对一条记录做改动时(这里的改动可以指INSERT、DELETE、UPDATE),都需要把回滚时所需的东西记下来。比如:
MySQL把这些为了回滚而记录的这些内容称之为撤销日志或者回滚日志(即Undo Log)。注意,由于查询操作(SELECT)并不会修改任何用户记录,所以在杳询操作行时,并不需要记录相应的Undo日志
此外,Undo Log会产生Redo Log,也就是Undo Log的产生会伴随着Redo Log的产生,这是因为Undo Log也需要持久性的保护。
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 |
+------------------+-------+
虽然InnoDB1.1版本支持了128个rollback segment,但是这些rollback segment都存储于共享表空间ibdata中。从lnnoDB1.2版本开始,可通过参数对rollback segment做进一步的设置。这些参数包括:
innodb_undo_directory:设置rollback segment文件所在的路径。这意味着rollback segment可以存放在共享表空间以外的位置,即可以设置为独立表空间。该参数的默认值为“./”,表示当前InnoDB存储引擎的目录。
innodb_undo_logs:设置rollback segment的个数,默认值为128。在InnoDB1.2版本中,该参数用来替换之前版本的参数innodb_rollback_segments。
innodb_undo_tablespaces:设置构成rollback segment文件的数量,这样rollback segment可以较为平均地分布在多个文件中。设置该参数后,会在路径innodb_undo_directory看到undo为前缀的文件,该文件就代表rollback segment文件。
1.每个事务只会使用一个回滚段(rollback segment),一个回滚段在同一时刻可能会服务于多个事务。
2.当一个事务开始的时候,会制定一个回滚段,在事务进行的过程中,当数据被修改时,原始的数据会被复制到回滚段。
3.在回滚段中,事务会不断填充盘区,直到事务结束或所有的空间被用完。如果当前的盘区不够用,事务会在段中请求扩展下一个盘区,如果所有已分配的盘区都被用完,事务会覆盖最初的盘区或者在回滚段允许的情况下扩展新的盘区来使用。
4.回滚段存在于Undo表空间中,在数据库中可以存在多个Undo表空间,但同一时刻只能使用一个Undo表空间。
5.当事务提交时,InnoDB存储引擎会做以下两件事情: 1.将Undo Log放入列表中,以供之后的purge(清洗、清除)操作 2.判断Undo Log所在的页是否可以重用(低于3/4可以重用),若可以分配给下个事务使用
未提交的回滚数据(uncommitted undo information):该数据所关联的事务并未提交,用于实现读一致性,所以该数据不能被其他事务的数据覆盖。
已经提交但未过期的回滚数据(committed undo information):该数据关联的事务已经提交,但是仍受到undo retention参数的保持时间的影响。
事务已经提交并过期的数据(expired undo information):事务已经提交,而且数据保存时间已经超过undo retention参数指定的时间,属于已经过期的数据。当回滚段满了之后,会优先覆盖"事务已经提交并过期的数据"。
当我们开启一个事务需要写Undo log的时候,就得先去Undo Log segment中去找到一个空闲的位置,当有空位的时候,就去申请Undo页,在这个申请到的Undo页中进行Undo Log的写入。我们知道MySQL默认一页的大小是16k。
为每一个事务分配一个页,是非常浪费的(除非你的事务非常长),假设你的应用的TPS(每秒处理的事务数目)为1000,那么1s就需要1000个页,大概需要16M的存储,1分钟大概需要1G的存储。如果照这样下去除非MySQL清理的非常勤快,否则随着时间的推移,磁盘空间会增长的非常快,而且很多空间都是浪费的。
于是Undo页就被设计的可以重用了,当事务提交时,并不会立刻删除Undo页。因为重用,所以这个Undo页可能混杂着其他事务的Undo Log。Undo Log在commit后,会被放到一个链表中,然后判断Undo页的使用空间是否小于3/4,如果小于3/4的话,则表示当前的Undo页可以被重用,那么它就不会被回收,其他事务的Undo Log可以记录在当前Undo页的后面。由于Undo Log是离散的,所以清理对应的磁盘空间时,效率不高。
如上图,可以看到,Undo Log日志里面不仅存放着数据更新前的记录,还记录着RowID、事务ID、回滚指针。其中事务ID每次递增,回滚指针第一次如果是INSERT语句的话,回滚指针为NULL,第二次UPDATE之后的Undo Log的回滚指针就会指向刚刚那一条Undo Log日志,以此类推,就会形成一条Undo Log的回滚链,方便找到该条记录的历史版本。
在更新数据之前,MySQL会提前生成Undo Log日志,当事务提交的时候,并不会立即删除Undo Log,因为后面可能需要进行回滚操作,要执行回滚(ROLLBACK)操作时,从缓存中读取数据。Undo Log日志的删除是通过通过后台purge线程进行回收处理的。
在InnoDB存储引擎中,Undo Log分为:
Loginsert Undo Log是指在insert操作中产生的Undo Log。因为insert操作的记录,只对事务本身可见,对其他事务不可见(这是事务隔离性的要求),故该Undo Log可以在事务提交后直接删除。不需要进行purge操作。
Logupdate Undo Log记录的是对delete和update操作产生的Undo Log。该Undo Log可能需要提供MVCC机制,因此不能在事务提交时就进行删除。提交时放入Undo Log链表,等待purge线程进行最后的删除。
以下是Undo+Redo事务的简化过程:
假设有2个数值,分别为 A=1 和 B=2 ,然后将A修改为3,B修改为4
1. start transaction;
2.记录A=1到Undo Log;
3. update A = 3;
4.记录A=3 到Redo Log;
5.记录B=2到Undo Log;
6. update B = 4;
7.记录B=4到Redo Log;
8.将Redo Log刷新到磁盘;
9. commit
Redo Log 进行恢复
Undo Log 发现有事务没完成进行回滚。
流程图:
《MySQL是怎样运行的--从根儿上理解MySQL》—小孩子4919(https://juejin.cn/book/6844733769996304392)
分享文章:图文结合带你搞定MySQL日志之Undolog(回滚日志)
文章URL:http://www.shufengxianlan.com/qtweb/news5/133855.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联