Ryan-Git
Results
68
comments of
Ryan-Git
那就比较奇怪了,确认下源端为啥执行慢?预期执行的 sql 应该是`select * from xx where id > xxx limit 10000`,不应该花 4~5 秒。 不是,是调低`input.config.table-scan-batch `,调高`input.config.batch-per-second-limit`。
哦。。。那就不是同步的问题了。类似`mysql`自身的主从延迟,大事务是在`commit`时候才刷`binlog`的,这期间`gravity`也没法同步。
1、可以看下具体场景 2、datax 我记得是扫表的,不是走的 binlog,自然没有这个问题。有条件可以跟 canal 或者 mysql 自身的主从比较一下,或者让 gravity 直接输出 binlog 看看。
唯一索引需要额外判断冲突,是会慢一点。但慢这么多确实不符合预期,我看下。
我在`MySQL`上试了一下上面提供的例子,几乎没有差别。你也试试? 这样的话看下目标侧为什么慢?前几年唯一索引`TiDB`似乎有锁冲突比较严重的问题,现在不太清楚情况。
看起来关系不大,截图的监控是阻塞在目标端。可以直接看`output`延迟相关的指标。
具体怎么丢失?直接写 mysql 应该没问题的。 序列化的话 json 本来就没有 decimal
有没有完整的堆栈,这个只有一行-。-
@selectliu 你手动进容器看看日志,这个 ELK 应该没把多行日志导出来。
@selectliu 再试一下。 其实应该在pr分支测的,有问题这个issue再打开吧。