解决Debezium搭配OpenLogReplicator抽数丢弃第1条变更消息的问题

问题描述

debezium结合OpenLogReplicator（olr）捕捉Oracle行级变更数据，当debezium结束snapshot阶段数据同步后会通过olr开始streaming阶段的变更数据同步。测试发现执行多次update操作后，第1次update操作没有被捕捉。

排查过程

在olr进程所在服务器上抓下包，然后执行两次update操作，看看第一次update事件是否到达debezium。
先查看debezium日志：

可以看到streaming阶段，debezium与olr交互确认起始SCN（startScn）值：12038484
然后看看抓包数据：

olr会产生3条JSON消息代表一次事务提交，我们看到有两次commit，说明两次update事件都发送到debezium了。
第一次update的scn值得注意，我们发现op为begin的scn比startScn小，而op为commit的scn刚好与startScn一致。
查看debezium olr相关的源码，在OlrNetworkClient.java中看到：

从源码可以明显看到当事件event的scn小于startScn时，该消息会被丢弃，直到找到符合条件的事件为止。
虽然定位到了问题所在，但为什么一开始协商好了起始scn值后，olr还要发出小于该值的scn。。
直接改源码恐怕不是首选做法，还是去olr官方使用指南找找答案。
olr的配置参数是挺丰富的，直接搜索关于scn的参数，我们发现确实有一个叫scn的参数：

scn默认值是0，查看了下OpenLogReplicator.json配置文件，没有配置这个参数，那么olr是根据什么生成该值的暂不清楚，不过我们发现scn取2表示所有的增删改操作SCN值会从commit SCN值复制过来，从前面的抓包数据可以看到，第一次update消息的commit SCN值正好等于startScn，debezium不会将其丢弃，那么可以快速验证下。
修改olr配置文件重启后再次测试，在kafka消息队列发现了久违的第1条update事件消息，至此问题解决。