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)后续的可见性判断比较复杂,文中没有详细说明