MySQL的redo log、undo log、binlog

一、MySQL日志文件类型

  • 重做日志(redo log)
  • 回滚日志(undo log)
  • 二进制日志(binlog)
  • 错误日志(errorlog)
  • 慢查询日志(slow query log)
  • 一般查询日志(general log)
  • 中继日志(relay log)

   其中,比较重要的包括 redo log 、 undo log 和 binlog。

   redo log 是重做日志,提供前滚操作;undo log 是回滚日志,提供回滚操作。

二、几种日志的对比

2-1、用途

   redo log

     确保事务的持久性。

     如果在发生故障的时间点(比如系统宕机),尚有数据未写入磁盘,在重启mysql服务的时候,根据redo log进行重做,从而达保证事务的持久性。

   undo log

     首先明确undo log绝对不是redo log的逆过程。它可以保存事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制(MVCC)下的读。

   binlog

     1. 用于复制,在主从复制中,从库利用主库上的binlog进行重播,实现主从同步。

     2. 用于数据库的基于时间点的还原。

2-2、存储内容、格式

   redo log

     物理格式的日志,记录的是物理数据页面的修改的信息(数据库中每个页的修改),面向的是表空间、数据文件、数据页、偏移量等。

   undo log

     逻辑格式的日志,在执行undo的时候,仅仅是将数据从逻辑上恢复至事务之前的状态,而不是从物理页面上操作实现的,与redo log不同。

   binlog

     逻辑格式的日志,可以简单认为就是执行过的事务中的sql语句。

     但又不完全是sql语句这么简单,而是包括了执行的sql语句(增删改)反向的信息。比如delete操作的话,就对应着delete本身和其反向的insert;update操作的话,就对应着update执行前后的版本的信息;insert操作则对应着delete和insert本身的信息。

     因此可以基于binlog做到闪回功能。

2-3、日志生成

   redo log

     事务开始之后就产生redo log,redo log的落盘并不是随着事务的提交才写入的,而是在事务的执行过程中就开始写入。在发出事务提交指令时,先保证缓存中的redo log写入完毕,才执行提交动作。

   undo log

     事务开始之前,根据当前版本的数据生成undo log;产生undo日志的时候,同样会伴随类似于保护事务持久化机制的redo log的产生。

   binlog

     事务提交的时候,一次性将事务中的所有sql语句按照一定的格式记录到binlog中。

     这里与 redo log 相比最明显的差异就是redo log 在事务开始之后就开始逐步写入磁盘。

2-4、删除策略

   redo log

     当对应事务的数据写入完成(持久化完成)之后,redo log的使命也就完成了,日志占用的空间就可以重用(redo log的日志文件是循环写入的)。

   undo log

     事务提交之后,undo log并不会马上被被删除,而是放入待清理的链表。由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息,决定是否可以清理undo log的日志空间。

   binlog

     binlog的日志文件是追加写入,也就是文件写到一定大小以后会切换到下一个,不覆盖原有记录。不过同时binlog的默认行为是,对于非活动的日志文件,在生成时间超过expire_logs_days配置的天数之后,会被自动删除。

2-5、redo log 与 binlog 的区别

  • 作用不同:redo log是保证事务的持久性的,是事务层面的——是innodb层产生的;binlog作为还原的功能,是数据库层面的。保护数据的层次是不一样的。
  • 内容不同:redo log是物理日志,是数据页面的修改之后的物理记录;binlog是逻辑日志,可以简单认为记录的是sql语句。
  • 关于恢复数据的效率:基于物理日志的redo log恢复效率要高于语句逻辑日志的binlog。

三、两阶段提交

   redo log 保证的是数据库的 crash-safe 能力。采用的策略就是常说的“两阶段提交”。

   一条update的SQL语句是按照这样的流程来执行的:

   将数据页加载到内存 → 修改数据 → 更新数据 → 写redo log(状态为prepare) → 写binlog → 提交事务(数据写入成功后将redo log状态改为commit)

   只有当两个日志都提交成功(刷入磁盘),事务才算真正的完成。

   一旦发生系统故障(不管是宕机、断电、重启等等),都可以配套使用 redo log 与 binlog 做数据修复。

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

推荐阅读更多精彩内容