undolog实现事务原子性,redolog实现事务的持久性

undolog可以实现事务的原子性,还可以用来实现MVCC。其原理是,(开启事务后)在操作任何数据前,先将原数据备份到undolog,然后对数据进行修改,如果此过程中出现异常,或执行了rollback语句,可利用undolog中备份的数据恢复到事务开始之前的状态。

假设有A、B两个数据,值分别为1,2。 进行+2的事务操作。

A.事务开始.

B.记录A=1到undo log.

C.修改A=3.

D.记录B=2到undo log.

E.修改B=4.

F.将undo log写到磁盘。

G.将数据写到磁盘。

H.事务提交

对于数据的操作,都是先读到内存中,然后在内存中修改,最后将数据写到磁盘。

之所以能保证原子性,是因为:

A. 更新数据前记录Undo log。

B. 为了保证持久性,必须将数据在事务提交前写到磁盘。只要事务成功提交,数据必然已经持久化。

C. Undo log必须先于数据持久化到磁盘。如果在G,H之间系统崩溃,undo log是完整的,可以用来回滚事务。

D. 如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。

缺点:每个事务提交前将数据和Undo Log写入磁盘,这样会导致大量的磁盘IO,因此性能很低。

所以,为了提升性能,可以在写数据到磁盘前,先写redolog,这就是wal预写日志机制,这样先写redolog日志,数据只需先写到内存,因为redolog是顺序写,而数据落盘则是随机写,要慢得多。 这样,当系统崩溃时,虽然数据没有持久化,但有redolog撑着,数据也不会丢。(innodb_flush_log_at_trx_commit  这个参数设置为2时,那么redolog每次不需落盘,而是写到os cache中(一定时间后再flush到磁盘),这样性能又大大提升,只要操作系统不宕,即便mysql宕了,数据也不会丢)

Undo + Redo事务的简化过程

A.事务开始.

B.记录A=1到undo log.

C.修改A=3.

D.记录A=3到redo log.

E.记录B=2到undo log.

F.修改B=4.

G.记录B=4到redo log.

H.将redo log写入磁盘。

I.事务提交

通过undo保证事务的原子性,redo保证持久性。

转载自:https://blog.csdn.net/shaolong1013/article/details/98462242

但是!!!基于以上的过程,mysql一个事务操作依旧十分繁琐,这也就是其在并发场景下需借助于nosql来提升性能


redolog和undolog属于innodb,而在mysql的server层还有一个binlog,其作用是误操作后需要靠它来恢复数据以及主从复制, mysql在update一行数据的时候:

1.执行器先找引擎取id=n这一行,id是主键,引擎直接用树搜索到这一行

2.执行器拿到引擎给的行数据,把这个值加1,得到新的一行数据,再调用引擎接口写入这行新数据

3.引擎将这行数据更新到内存中,同时将这个更新操作记录到redolog中,此时redolog处于prepare状态,然后告知执行器执行完成,随时可以提交事务

4.执行器生成这个操作的binlig,并写入磁盘

5.执行器调用引擎的提交事务接口,引擎吧刚刚写入的redolog改成提交(commit)状态,更新完成

将redolog的写入拆成两个步骤,prepare和commit,这就是两阶段提交,其目的是为了让两份日志(redolog和binlog)之间的逻辑一致

这两个日志有三点不同:

1.redolog是innodb特有,binlog是mysql server层实现的,所有引擎都可以使用,

2.redolog是物理日志,记录的是在某个数据页上做了什么修改,binlog是逻辑日志,记录的是这个语句的原始逻辑,

3.redolog是循环写的,空间固定会用完,binlog是可以追加写入的,追加写是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。

redolog和binlog互相是不可替代的,redolog的作用是提升数据写入时的性能,并保证事务的持久化特性,以及崩溃恢复的能力,而binlog 是无法支持崩溃恢复,因为它没有能力恢复“数据页”。  而binlog也有着redolog无法替代的功能,一个是归档。redo log 是循环写,写到末尾是要回到开头继续写的。这样历史日志没法保留,redolog 也就起不到归档的作用。还有很多公司有异构系统中使用到的组件(比如es,redis等),这些系统就靠消费 MySQL 的 binlog 来更新自己的数据。关掉 binlog 的话,这些下游系统就没法输入了。总之,由于现在包括 MySQL 高可用在内的很多系统机制都依赖于 binlog,所以“鸠占鹊巢”redo log 还做不到。


最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,383评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,522评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,852评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,621评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,741评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,929评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,076评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,803评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,265评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,582评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,716评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,395评论 4 333
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,039评论 3 316
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,798评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,027评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,488评论 2 361
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,612评论 2 350

推荐阅读更多精彩内容