He3DB数据页正确性校验
He3DB正确性校验主要通过日志回放数据页与主实例数据页比较实现,He3DB主实例业务操作的数据页正确性,目前,只有通过备实例重做日志看能不能得到与主实例一样的数据页实现,如果He3DB主实例数据页本身操作就错误了,备实例日志重做的逻辑正确rm_redo在重做过程中有很多断言,可以变向校验主实例数据页的正确性,但这种校验方式可能不会覆盖全部场景,后期会补充对主实例正确性做相关校验。另外,He3DB本身支持PG为主He3DB为备功能,默认PG主实例操作的数据页本身不会出错,那He3DB做为备机只要重做PG为主产生WAL产生的数据页与PG为主产生的数据页进行比较,那基本能保证He3DB重做日志获取数据页的正确性。He3DB 100%兼容Postgres的,pg主备本身支持数据页校验逻辑,通过开启wal_consistency_checking参数即可,我们这边借助这个参数,然后对每个回放的日志进行校验。
He3DB数据页校验逻辑
原生pg数据页校验逻辑(pg14.2)
原生pg重做日志在startupxlog中,rm_redo为指针函数负责重做heap、btree、hash等表索引数据页,数据页重做完成后,record->xl_info&XLR_CHECK_CONSISTENCY会校验此wal是不是要与pg主的数据页检查,正常情况下,wal_consistency_checking='all’开启情况下,主实例更新删除插入等操作除了记录相关操作日志还会保存主实例此刻数据页。

如果备回放到某个lsn 与主此刻lsn对应的数据页不一致时,就会coredump

He3DB数据页校验逻辑
因为He3DB是并行回放以及查询进程回放数据页,因此我们把数据页校验放到回放函数里面。每次回放一个LSN就会去检查下数据页是否与wal中保留的主实例此lsn的数据页是否一致,从而达到数据页正确性校验。

He3DB数据页正确性校验与问题解决
Pg为主He3DB为备场景
pg为主he3db为备具体搭建流程这里就不在赘述,搭建完成后我们去跑postgres的regress回归测试,因为wal对数据页的操作包含page记录信息,可能导致wal长度非常的大,之前跑一次regress只有几百MB wal,开启wal_consistency_checking会生成5G以上的wal。因为He3DB对原生Wal进行拆分处理,所有rm_redo中都是对单个页进行回放,第一次跑regress就直接core了。

问题分析:
1.查看EndRecPtr是0x2100820,He3DB日志拆分后一个wal最多存一个数据页,看到表2610第2个block在全页后只做了一次修改,修改后数据页对不上了。

2.分析此日志类型是更新操作,找到具体rm_redo函数指针的heap_redo进行分析。
日志中new off 45 xmax 0 blkref#0 1663/16385/2610 blk 2表示修改表2610的第二个block数据,一个数据页8k,我们查看heap_xlog_update逻辑

newoff值为45,带入PageGetItemId函数获取lp值lp_off=352,此值带入PageGetItem函数打印HeapTupleHeader值,发现replay_image_masked与primary_image_masked修改的hup记录t_ctid存在差异

对比原生pg的heap_xlog_update逻辑发现ItemPointerSet(&newtid, newblk, xlrec->new_offnum);去置t_ctid在if条件之外,而我们拆wal把此函数放到的if条件之内导致存在有情况下t_ctid未置值后续直接使用newtcid栈变量未初始化赋了随机值。

后面将ItemPointerSet(&newtid, newblk, xlrec->new_offnum);放到if条件外面,再跑回归测试,得到了回放完数据页与主实例完全一样的数据页。
He3DB为主数据页校验
同样开启wal_consistency_checking,然后跑regress回归测试,因为He3DB主实例包含多级缓存,这一块数据页正确性后面会考虑其他方案校验,目前校验主数据页是不是正确,一方面看备机能重做能得到与主实例完全一样的数据页,另外通过备机重做日志一些断言来判断。
小结
He3DB数据正确性校验,目前开发主要做了备机回放逻辑正确性校验工作,对于在事务场景下多个数据页某个一致性点一起可见或者不可见在代码逻辑中对于一个原生pg的wal拆分多条记录,我们将多条wal记录作为一个mtr点,对于这个mtr点内wal记录涉及的block数据实现了要么一起可见要么一起不可见。除此之外,我们在测试方面会用具体正确性测试框架验证He3DB相关数据页的正确性。




