数据增量同步检验问题

[aoxg2019]

如题，在 mysql 通过 canal 发送数据到 kafka 后，进行增量同步数据到 es ，现在的问题是如何检验增量同步过程中有没有问题呢？这个工作可能要周期运行！举例如下:此刻比对昨天以前的增量数据的总数，及抽样某个表的一些行来对比 es 中的数据。查 mysql 之前，数据无变化，查 es 期间，mysql 中某些数据已经被更新或者删除了，但数据更新还没写入 es ，这样查出来的数据比对结果不太一致。各位有什么好的方案吗？

[aoxg2019]

ps:表有 update_time 时间。

[aoxg2019]

还是说增量同步过程中不需要检验？

[q474818917]

参考 mysql 主从同步的校验机制

[EXChen]

我们以前是数据同步异常会有告警，然后人工排查，有问题重新回放一下 binlog 。

[skymei]

我们项目也是这种架构，Mysql canal ES,短时间内的差异是一定会存在的，要求不高的话就定时全量更新下，数据结构不复杂全量一次也很快

[aoxg2019]

@skymei 定时全量更新压力有点大，相当于定时全量同步了。

[aoxg2019]

@EXChen 关键点就在于这个同步异常的确定呀。数据检验就是看有没有异常

[limbo0]

实时同步这方面确实有风险, es 因为可读延迟并不能那么实时同步也不好验证, 最好是做一些关键指标的对比, 总量, sum, 有一定误差也算正常

[aoxg2019]

@limbo0 您看这样行不行呢，比如我今天要校验昨天增量同步的数据，我先在 mysql select update_time=昨天的 ，如果今天有数据更新 /删除，并且在 select 的结果集中，在比对两边数据的时候后剔除这部分数据可以吗

[canbingzt]

最近刚好看到相关的技术
https://debezium.io/

[liprais]

你得先想明白误差从何而来

[aoxg2019]

@liprais 大佬可以详细说说吗

[7911364440]

这不就是 CAP 吗，非要强一致性的话就只能实时同步了，并且在 mysql 写入之后，同步到 es 之前不允许查询

[liprais]

@aoxg2019
https://flyingice.github.io/2019/04/21/mysql_redolog.html
这个讲的很清楚了
基本上如果 mysql 没挂过就不用担心一致性的问题

[limbo0]

@liprais #14 这个决定了 mysql 端没有问题, 但是有可能 es 端有问题, 无法写入等情况也得考虑下
@aoxg2019 #9 挺好的方法哈

[rekulas]

我现在只在源头校验，实现 canal 消费者的时候尽量考虑鲁棒性，单进程插入，在读取 sql ，拼装 sql ，进出队列等逻辑处都需确认成功，一旦不成功就丢入 redis 待处理队列(包括丢队列都是循环重试的不成功一直重试)并通知人工介入，这样理论上来说不会有丢失的情况只是有延迟
目前来看运行很好，因为可能出错的地方都被考虑了，只是有时候手动改了数据库结构时 canal 会失败需要人工维护下基本几个月一次
当然也可能存在意外，但我觉得这种概率很小(几年都未必能遇到一次)暂时不在考虑范围

[miniliuke]

我是根据《 DBLog: A Watermark Based Change-Data-Capture Framework 》的原理做了，增量过程中的全量数据校验，论文本身是讲增量过程中的全量传输的。举一反三，我整了个增量过程中的数据全量校验，还水了一篇论文。但是我的目标端也是关系型的，es 不清楚支不支持（主键排序+OFFSET ）的取数据方式

[miniliuke]

@canbingzt 我就是看了 debezium 增量快照的实现原理，搞的增量过程中的全量数据校验，应该就是 @aoxg2019 要的东西

[aoxg2019]

@rekulas 这种也是一种比较好的方式，在源头把控。现在 leader 要求必须做检验.哈哈

[aoxg2019]

@miniliuke 感谢大佬，我来看看这个框架