Ryan-Git

Thanks for ur work. How about tests? We need to make sure it correctly writes to mysql and serializes to json.

what does it mean by "if i restart gravity it can't synchrone the data"? we save the binlog gtid in source db, and continues on restart, like the way mysql...

ok I got it. you start the task, add the time column in target db, and the task continues with new column having default value filled by mysql(gravity don't know...

the recorded time seems only useful in make statistics of gravity itself. While it's only a few microseconds later than source, it's almost meaningless. What do you do with it?

为啥要 binlogPositionId 存本地？直接存 gtid 不行吗

还有个问题，不能每个 pipeline 都干这个事情，应该一个实例只做一次。 我觉得应该用 gtid 做键，一来避免不同 pipeline 重复，二来方便查询。其次不仅要保存执行后的表结构，还要保存所执行的语句。最后还需要一个归档/快照机制，不然一个实例的 ddl 时间长了可能还是太多。

I'm ok with it. The content(``) seems all right. @ming-relax what about you?

It seems proxy is needed for raw picture, build status and user avatar etc..

目前确实是这样实现的。主要原因是消费端并不是很容易处理 DDL，除非是单 partition 的 topic。 在多 partition 的前提下，如果下发 ddl，由于不同 partition 的消费不能保证顺序，同一个组里的某个客户端消费到 ddl 时，可能有在消费 ddl 执行前数据的客户端，可能有在消费 ddl 执行后数据的客户端，无法保证 ddl 双向 barrier 的语义。 不知道你这边场景是什么样的，针对这个问题想怎么解决呢？如果有好的想法我们也很有兴趣实现。

所以是用每个表只用一个 queue 的方式实现的对吧。跟前面说的单 partition 一个意思。 rmq 不太清楚，kafka 上这个方式吞吐量有瓶颈。我们的环境下单 partition 大概最多 1w rps，流量大一点的表就不太够用了。 不过在流量不是很大的情况下确实也是一个办法，我们增加一个按库名+表名路由 partition 的功能是不是能满足需求？