flinkCDC抽取mysql数据问题记录
情景描述
利用flinkcdc抽取mysql数据到kafka,再从kafka消费数据到Doris。
上游mysql的delete操作,在下游Doris做成逻辑删除,即表增加一列is_delete_flg做为是否删除的标志。Doris表设置为unique模型,保证端对端的幂等性,保证数据不会重复。其中Doris的unique模型表需要设置sequence列。
flinkcdc官网介绍的op_ts操作时间正好可以做为sequence。
在同步了两百多张表后,发现有一张表Doris的is_delete_flg=1,也就是逻辑删除的状态,而mysql表里并没有删除。
定位问题
定位问题的思路就是打印原始数据看看,直接flinkcdc读取过来然后做print打印原始数据
1 |
|
发现delete的”ts_ms”:1654866586278和insert的 “ts_ms”:1654866586278是在同一毫秒发生,此时到Doris就会随机取一条数据,可能取到delete的那一条,所以标志is_delete_flg=1,而mysql由于还有insert同一条数据,故而发生了👆描述的问题。
猜想上游发生此数据现象的原因
可能delete和insert放在同一个事物中提交了,于是找上游要了处理逻辑
发现真是批量提交了
解决方案
1.可以将insert操作的op_ts➕1s使得和delete的操作时间不同
2.因为数据量比较小,我直接采用了select方式的datax方式抽取数据
觉得不错的话,支持一根棒棒糖吧 ୧(๑•̀⌄•́๑)૭
wechat pay
alipay
flinkCDC抽取mysql数据问题记录
http://yuting0907.github.io/posts/95cefbee.html