zhanjian comments

Results 23 comments of


                                            zhanjian

Who is using Gravity?

Synchronize rds Mysql to Kafka and then consumption data to es or phoenix in test environment, Plan to synchronize data in production my company is qimai in hefei

> 从监控看问题是读源端慢。源端没有主键只有联合唯一键？这样（联合唯一键批量）读是会比较慢的，跟同步链路本身关系不大。可以尝试调低批量调高并发，具体还是要看下源端的情况。是有主键的，简化后的表结构如下 CREATE TABLE sqldataviewtest. `test_aaa` ( `id` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT 'id', `cc_id` varchar(32) NOT NULL DEFAULT '' , `domain_id` varchar(64) NOT NULL...

带有唯一索引的表，在进行大批量数据事务的操作下，同步速率低

> 从监控看问题是读源端慢。源端没有主键只有联合唯一键？这样（联合唯一键批量）读是会比较慢的，跟同步链路本身关系不大。可以尝试调低批量调高并发，具体还是要看下源端的情况。这里调低批量调高并发是指调 scheduler 调大nr-worker 及调小 queue-size吗?

带有唯一索引的表，在进行大批量数据事务的操作下，同步速率低

> 那就比较奇怪了，确认下源端为啥执行慢？预期执行的 sql 应该是`select * from xx where id > xxx limit 10000`，不应该花 4~5 秒。 > > 不是，是调低`input.config.table-scan-batch `，调高`input.config.batch-per-second-limit`。可能是我表述有误，是在增量的模式下，mysql端进行大批量的更新操作如 insert into xxx select * from xxxx, 在同步到tidb及kafka时...

带有唯一索引的表，在进行大批量数据事务的操作下，同步速率低

> > 那就比较奇怪了，确认下源端为啥执行慢？预期执行的 sql 应该是`select * from xx where id > xxx limit 10000`，不应该花 4~5 秒。 > > 不是，是调低`input.config.table-scan-batch `，调高`input.config.batch-per-second-limit`。 > > 不好意思。我表述有误，是在增量的模式下，mysql端进行大批量的更新操作如 insert into xxx select *...

带有唯一索引的表，在进行大批量数据事务的操作下，同步速率低

> 看着不像是binlog产生慢导致的， 1）有不带唯一索引的表也有类似的大事务更新操作，但同步会很快， 2）上面的表结构，我在用datax导入的测试数据的时候，他那个是微批批量写入的机制，datax导入完了。这个时候观察gravity 采集的同步速率也不快

带有唯一索引的表，在进行大批量数据事务的操作下，同步速率低

> 1、可以看下具体场景 2、datax 我记得是扫表的，不是走的 binlog，自然没有这个问题。有条件可以跟 canal 或者 mysql 自身的主从比较一下，或者让 gravity 直接输出 binlog 看看。 1、我这边做了一个小测试，不能完全复现，但是有唯一索引会比没有唯一索引的慢一些 2、gravity的输出端output.type 直接改成stdout，同步速率会很快 ## 测试案例 ``` -- 建内存表 CREATE TABLE `vote_record_memory` ( `id` INT (11)...