MySQL内核月报 2015.02-TokuDB · 特性分析· 日志详解-阿里云开发者社区

开发者社区> 阿里云数据库> 正文

MySQL内核月报 2015.02-TokuDB · 特性分析· 日志详解

简介:

TokuDB的日志跟InnoDB不一样,它有两类文件:

  1. redo-log文件(以.tokulog[序号]为扩展名)
  2. rollback日志文件(tokudb.rollback)

接下来就简单唠唠这两类文件的内部细节。

1) redo-log

记录的不是页而是对Fractal-Tree索引的操作日志。 log格式:


content里记录的是具体的日志内容,比如insert操作,content就是:


TokuDB在做恢复的时候,会找到上次checkpoint时的LSN位置,然后读取log逐条恢复。

为了确保log的安全性,redo-log也支持从后往前解析。

当一个log的MAX_LSN小于已完成checkpoint的LSN时,就表明这个log文件可以安全删除了。

那么问题来了:

如果用户执行了一个“大事务”,比如delete一个大表,耗时很长,log文件岂不是非常多,一直等到事务提交再做清理?

不用的,这就是tokudb.rollback的作用了。

2) tokudb.rollback

用户的事务操作(insert/delete/update写操作)都会写一条日志到tokudb.rollback,存储的格式是:


记录日志伪码如下:


如果是事务,每个操作会写2条日志(1条redo,1条rollback)。

如果用户执行了commit/rollback,TokuDB会根据txnid在tokudb.rollback里查到key(如果该entry不在cache里),再根据key在索引文件里找到相应的事务信息并做相应的commit/rollback操作。

tokudb.rollback可以看做是一个事务的undo日志,记录的是<txnid,key>的关系映射。

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里云数据库
使用钉钉扫一扫加入圈子
+ 订阅

帮用户承担一切数据库风险,给您何止是安心!

官方博客
链接