关于undo日志删除时机和建立read view 时选择版本算法疑惑

Question

1. 对于undo update 日志删除的时机
   对于purge线程来说 它删除日志是通过扫描方式进行选择性删除, 此时删除的判断依据是什么? 当前undo日志没有被标记为快照并且是事务结束的版本, 那么当前的记录update日志和更早期update的日志就会被删除, 问题点在于它如何区分提交和未提交的? 还是通过undo日志记录的事务id和系统的活跃id做对比吗? 但是如果事务结束了, 但是比活跃事务id大怎么办呢
2. 对于建立快照的算法疑惑
   老师视频中说建立快照是通过递归的方式, 从当前数据的事务id 和 系统活跃id做对比, 如果大于等于活跃id, 就去undo日志,根据db_roll_ptr 取记录的undo日志数据, 再判断该undo日志记录的事务id和系统活跃id, 重复上述过程, 但是如果有下面这样一个场景
   场景: 事务A快照读id=1的记录, 事务B在事务A之后创建, 并修改id=1的记录, 建立undo日志, 并进行提交, 此时undo日志不会删除事务A建立的快照版本的undo日志, 此时又有一个新建的事务C 快照读读取id=1的记录,
   问题: 如果是拿记录的事务id和当前系统的活跃id做对比, 此时事务C应该建立快照读取的数据应该是事务A那个版本的快照, 但是测试发现不是的, 事务c的快照是最新的提交版本数据
   这两个问题有共通的地方 就是事务结束判断, 问题描述比较长, 但是描述的还算清晰, 麻烦老师了

Answer 1

翔仔 2020-04-09 01:26:02

同学好，你这个问题需要仔细看源码去了解才可以，我这周在赶录新出的spring源码课程，外加平日加班，暂时没有时间去研究，先留做遗留问题来处理，这个不着急的话下周有时间我再看看，我先把问题记录下来，感谢支持与理解：）

• 提问者 坐看落花 #1

  老早就想跟老师说, 你工作时长太长了, 加班还要做课程, 身体才是最重要的, 有好身体才能做更长时间的程序员. 感谢老师的及时回复

• 翔仔 回复 提问者 坐看落花 #2

  哈哈，同学这个问题我一看到就感觉真难，我估计还会难倒工作好多年的老员工，可以好好研究一下，待到花开时：）
  感谢同学的理解和关心，等熬过这几周好好休息一下：）

• 翔仔 回复 提问者 坐看落花 #3

  同学好，我大致抽空看了点，当事务提交后update_undo日志就会被置为需要purge来删除的状态，该状态记录在header page中，加入到history list中，并且将当前的undo段和最大的事务号加入purge队列。所以说事务提交会更新undo log的状态

点开查看后面2条评论