WBL论文:针对NVM设计日志记录及恢复协议

yzsDBA
关注

后写日志

Write behind logging

基本思想

NVM的优点是可字节寻址、接近内存的高性能、顺序访问和随机访问差距不大。2016年VLDB会议上《write behind logging》论文专门针对NVM设计了一种新的日志记录及恢复协议。主要思想是去掉了传统的append only的redo和undo日志,但仍然需要保留undo信息用来回滚未提交事务。事务提交前需要将该事务的所有修改强制刷盘,之后在log中记录commit标记,即这里所说的WBL。恢复过程中,通过分析commit标记将未提交的事务通过undo信息回滚掉。

而这篇论文在这个思想基础上又进行了一系列优化,下面介绍其机制。首先吐槽一下,这篇论文写得不是很清晰,理解起来比较困难。下面是深入理解后的机制,有不当地方还望指正。

机制

1、几个概念

DTT表中元组结构:事务ID+表ID+更改位置

数据页中的元组结构:

tuple id+trx id+begin commit时间戳+ end commit时间戳+上个版本号的tuple ID +data

Cp:该时间戳之后的提交的事务其数据不保证已经持久化到磁盘

2、一个事务操作过程

Begin;

执行操作,修改DRAM中的数据页

添加一个元祖到DTT表中,该元祖不包括插入后的值

Commit:

1)记录下各个该事务的提交时间戳t1

2)扫描DTT表得到该事务相关元组

3)计算cp和cd值

4)将DTT表中元组持久化到磁盘,此时元组中加上了提交时间戳t1

5)将cp和cd构成的WBL持久化到NVM

6)通知完成组提交,释放DTT

Rollback:

   1)通过DTT中信息进行回滚。

3、一个事务操作过程图示

若在trx6 commit的时间点,系统故障,那么重启时从WBL日志文件中遍历得到最后一个WBL即{4,(5,100)},得到活跃的事务为4,大于5的事务都未提交。分析到这里恢复就完成,即可接受新事务。

但是磁盘上的脏数据怎么处理?会启用一个单独的回收线程,扫描表中记录,若记录的时间戳大于5,比如事务6的记录,他是不可见的,即将它回收掉;对于1,3,2,5都是可见的,不做处理,对于4,他在组提交未提交的事务链表里,也将它回收掉。

4、缺点及疑惑

1)文中没有详细说明记录是如何回收的,是后续事务访问到进行判断处理,还是说只是另外回收线程全部扫描进行判断。数据量如果特别大的话,扫描的代价岂不是很大?全部扫描完后,才将不用的WBL回收掉?

2)如果在高可用场景下,无法满足要求,仍然需要相应的WAL进行复制

3)后续的可见性判断比较复杂,文中没有详细说明


声明: 本文由入驻OFweek维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。
侵权投诉

下载OFweek,一手掌握高科技全行业资讯

还不是OFweek会员,马上注册
打开app,查看更多精彩资讯 >
  • 长按识别二维码
  • 进入OFweek阅读全文
长按图片进行保存