Flink CDC2.1.1 varchar类型主键大表数据同步速度很慢的问题

[a120610114]

在使用FlinkCDC2.1.1 版本进行数据同步的时候我发现对于主键是varchar类型的大表数据（大约3000w左右的数据）数据同步非常慢，而且还经常报错。在查看日志的时候发现了这样的日志
fb72562c-845f-11ea-88a6-b8599fe5d1ea:1-244504311, row=0, event=0} for split MySqlSnapshotSplit{tableId=wxqyh_learnonline.tb_qy_examination_exam_user_ref, splitId='wxqyh_learnonline.tb_qy_examination_exam_user_ref:2031', splitKeyType=[idVARCHAR(32) NOT NULL], splitStart=[b6547e5906a64ae6a5b062492f1b4b91], splitEnd=[b66b1de7513043379a327af9086c8f80], highWatermark=null} 2022-01-07 00:28:28,429 INFO com.ververica.cdc.connectors.mysql.debezium.task.MySqlSnapshotSplitReadTask [] - Snapshot step 2 - Snapshotting data 2022-01-07 00:28:28,429 INFO com.ververica.cdc.connectors.mysql.debezium.task.MySqlSnapshotSplitReadTask [] - Exporting data from split 'wxqyh_learnonline.tb_qy_examination_exam_user_ref:2031' of table wxqyh_learnonline.tb_qy_examination_exam_user_ref 2022-01-07 00:28:28,429 INFO com.ververica.cdc.connectors.mysql.debezium.task.MySqlSnapshotSplitReadTask [] - For split 'wxqyh_learnonline.tb_qy_examination_exam_user_ref:2031' of table wxqyh_learnonline.tb_qy_examination_exam_user_ref using select statement: 'SELECT * FROMwxqyh_learnonline.tb_qy_examination_exam_user_ref WHERE id >= ? AND NOT (id = ?) AND id <= ?' 2022-01-07 00:28:31,217 INFO com.ververica.cdc.connectors.mysql.debezium.task.MySqlSnapshotSplitReadTask [] - Finished exporting 8093 records for split 'wxqyh_learnonline.tb_qy_examination_exam_user_ref:2031', total duration '00:00:02.788' 2022-01-07 00:28:31,222 INFO com.ververica.cdc.connectors.mysql.debezium.task.MySqlSnapshotSplitReadTask [] - Snapshot step 3 - Determining high watermark {ts_sec=0, file=mysql-bin.001188, pos=53630482, gtids=1935d4a6-2e71-11e9-9330-6c92bf5f0aed:450812989-484900678, 4ddb2c3f-6f05-11e9-8a9c-6c0b84d5a828:1-411556268,
这让我很疑惑，查看源码也是一样的


这是直接对varchar类型进行切分然后查询，当我用这个语句去数据库查询的时候发现非常慢

我想问下这种想象是正常的吗？设计的原理是什么？有没有什么办法可以提高这种varchar 大表数据的同步？

[a120610114]

@wuchong 大佬可以帮忙解答一下吗

[xiaoyu19950911]

非自增的主键每次分chunk都会去查一遍db，你的chunkSize看起来是默认大小，可以尝试一下调大chunkSize试试

[a120610114]

除了这个还有其他的办法吗？调整这个参数 debezium.min.row. count.to.stream.result 是否会有用呢？改为流式读取

[xiaoyu19950911]

你最好先看下速度很慢耗时在哪，如果是耗时在切片的话，那这个参数的调整也没有意义，其次，分片同步是没有使用debzium原生的全量同步逻辑的，所以调整这个参数也不会生效的，分片同步控制全量部分的参数为fetchSize

[a120610114]

其实我比较担心的是 非自增的主键的分片，如果表的数量太大的话 是不是后面会影响性能？或者说后期的时候根本读不出来。因为我的任务在运行了几个小时后就莫名挂了，这种情况出现了几次。但是如果是自增型主键的表的话 数据量更大都没有问题

[wuchong]

现在varchar 类型慢，一般是卡在前面计算切片的时候（要把所有切片都分好，才开始每个切片的读取）。有一个优化思路是异步切片：

1. enumerator 通过异步线程去切表的切片。
2. readers 来取切片的时候，只要有一个切片就能开始读取，就不用等所有切片分好。
3. reader 在读数据的过程中，enumerator 仍在异步分切片。

[wuchong]

cc @leonardBang

[a120610114]

@wuchong @xiaoyu19950911 @leonardBang 经过排查 是因为mysql 中的字符比较是忽略大小写的，这是很多数据库的一种常见方式。 但是在java Comparable 的比较中却是不忽略大小写的。 按照ASCII 编码 小写字母就是比大写字母大。这就是导致chunks 分布不均匀的原因。 建议说提供一个参数来控制是否大小写敏感 或者就忽略大小写敏感是否更好呢？

[leonardBang]

@wuchong @xiaoyu19950911 @leonardBang 经过排查 是因为mysql 中的字符比较是忽略大小写的，这是很多数据库的一种常见方式。 但是在java Comparable 的比较中却是不忽略大小写的。 按照ASCII 编码 小写字母就是比大写字母大。这就是导致chunks 分布不均匀的原因。 建议说提供一个参数来控制是否大小写敏感 或者就忽略大小写敏感是否更好呢？

@a120610114 非常感谢反馈和详细的排查，点赞！
这个比较应该和数据库保持一致，大多数数据库是忽略大小写的，那我们也应该忽略大小写，如果有的数据库是不忽略大小写的，那我们再去引入一个参数。有兴趣开个PR来修复吗？

[a120610114]

是的非常有兴趣

[gwqlovelinux]

scan.incremental.snapshot.enabled = false
回退到老的版本，不使用2.1的特性，这样就快起来了，小表建议加这个参数