KFS实时同步模块之Extractor模块长事务处理逻辑

KFS实时同步模块之Extractor模块长事务处理逻辑

关键字：

Kingbase FlySync、Extractor、长事务

关于数据同步的长事务

何为“长事务”，顾名思义长事务就是执行时间很长的事务，对长事务的理解要对比大事务，大事务是指执行语句很多的事务。大事务不一定是长事务，长事务不一定是大事务，大事务虽然含有很多条sql语句，但是可以在短时间内执行完，长事务虽然只有几条sql语句，却在执行后的很长一段时间才进行commit操作。在业务场景中，有的长事务的执行时间会达到数十个小时甚至更久，在此期间其他事务一直解析并且写入KUFL文件中并完成从源端到目标端的数据同步。当长事务没有执行结束如果程序出现意外中断或者用户自行结束程序，当下一次开启同步程序时，根据程序设置，为了保证同步数据的完整性，需要从oldestLSN开始解析，即大事务开始的LSN开始解析，此时会重复解析穿插在大事务中的其他已经完成同步的事务，虽然这些事务会在后续的判断中skip，不会重复写入KUFL中，但是重复的大量的解析wal依然会造成系统性能下降，因此需要对长事务进行处理。

断点解析技术

要想对大事务进行处理，首先要了解Extractor模块对wal日志解析逻辑，特别是断点解析逻辑。由于kingbase复制槽在进行增量读取时只能读取到已经提交的事务，如下图所示，当读取到下标为6的点时，此时由于事务1事务2还未提交，因此只读取到了事务3和事务4，若此时KFS异常停止，当再次启动时如何能保证数据的完整性？

首先需要记录断点，来标记一个再次启动时开始读取的位置。若断点记录为1，固然会将所有数据都读取到，但是同时也会导致事务3和事务4的重复解析。若断点记录为6，那么我们就无法读取到事务1和事务2。因此，将断点设置为：oldestLSN:commitLSN。oldestLSN代表了上次解析时还未提交的事务的开始的位置，commitLSN代表了上次解析时已经提交的最新事务最后的位置。

对于上图的场景，记录为1:6，再次启动时，从1开始读取数据，首先读取到5时，完整读取了事务3，这时判断5小于上次记录的6，表明这个事务已经解析过一次，所以直接丢弃。事务4也是如此，当读取到7时，完整读取了事务1，发现7大于我们记录的6，因此该事务保留。

大事务预警处理

基于上述断点解析技术，当程序在大事务执行中间出现终止，当系统再次启动时，多余的wal日志解析会带来系统性能的下降，因此当系统读到大事务时，需要进行预警处理。此功能需要在KES支持读取当前事务的endLSN条件下进行，当系统读到事务“BEGIN”标识后，会获取long类型的currentLSN和endLSN，这两个LSN号在数据库底层分别映射为wal日志地址，即当前事务执行开始语句的wal日志和commit语句的wal日志，由于内存地址的连续性，可以通过计算currentLSN和endLSN的差值来计算两条wal日志之间内存偏移量，内存越大就间接反应当前事务是否是一个长事务。此时设置参数maxTransactionCapacity，表示最大的长事务执行内存，用户可以自定义设置该参数，当时用户设置了该参数后，系统会判断当前事务currentLSN和endLSN的差值是否大于maxTransactionCapacity，如果大于系统会发出预警，告知用户当前在执行一个长事务，如果执行期间出现系统终止，则再次启动会对性能有影响，用户根据该预警，可以选择跳过该事务或者接受重启带来的性能下降的风险，继续解析该事务。

参考资料

KFS源码