TiCDC双Sink同步增量备份到S3速度慢

【 TiDB 使用环境】
生产环境 /测试/ Poc

【 TiDB 版本】
1.TiDB集群版本v5.4.0

2.TiCDC版本为v5.3.0 (v5.4.0 暂不支持写s3,故用回老版本v5.3.0)
/cdc version
Release Version: v5.3.0
Git Commit Hash: 8b816c9717a6d18430f93a6b212f3685c88d4607
Git Branch: HEAD
UTC Build Time: 2022-08-10 04:27:19
Go Version: go version go1.16.13 linux/amd64
Failpoint Build: false

【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
1.在一个集群里先是部署了主从集群同步,前期经过TiCDC的调优把sink TiDB的QPS从5k优化到最高支持45k左右,TiDB集群主从同步不存在瓶颈。
2.接着在相同的集群上,再开启一个新changefeed实现增量备份到S3,以满足不同场景的备份需求。
新创建一个TiCDC到S3的增量同步任务,该任务的同步QPS只有4.5k左右,而相同库表的主从同步能达到27k。
从配置任务来看,上游是完全相同的表,这两个任务的前面的puller、sorter、mouter都相同,有差异的地方是在cdc sink。

https://docs.pingcap.com/zh/tidb/stable/ticdc-sink-to-cloud-storage
官方这里说到从 TiDB v6.5.0 开始TiCDC 支持将行变更事件保存至存储服务 S3。
根据实践使用TiCDC在v5.4.0版本不支持写S3,我们使用V5.3.0旧版本能够支持写,目前实际使用中同步到S3的QPS在 4k-5k之间。

尝试的优化:
1)网络优化,确认在TiCDC节点到S3之间的写延迟大概在100ms以下,应该不存在网络延迟过高的问题。
2)参考【s3://bucket/prefix?worker-count=128&flush-interval=1m30s&file-size=33554432
】,通过调整worker-count等参数并未能提高同步到S3的速度。
3)扩容TiCDC节点,同步速度没有明显提升。



运行过程中集群没有内存、CPU或IO的性能瓶颈,想了解一下大佬们有没有其他办法在该版本下提高写S3的效率

比如在同步落后追数据时,可以看到一组对比数据:
对于主从同步Sink TiDB:puller (xxx:8300-resolved 48k,xxx:8300-kv 25k)->sorter (36k)->mounter (36k)->sink (35k)。
对于增量备份Sink S3:puller (xxx:8300-resolved 48k,xxx:8300-kv 25k)->sorter (4.5k)->mounter (4.5k)->sink (4.5k)

怀疑的地方在在sorter这里比较慢,目前per-table-memory-quota配置了100MB。

【资源配置】
资源配置如下:
CPU:amd64,56 (112 vCore)
内存:512GB
磁盘:2.9TB的NVME
万兆网卡

Linux 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

在使用中TiCDC和PD暂时混部,集群部署了3个TiCDC节点,单机部署2个TiKV,在测试和使用过程中排查机器资源充足,不不存在资源瓶颈。

S3的写入有瓶颈吗

基于s3的都有本地ssd缓存,不太可能是写S3的性能瓶颈

你们有aws技术专家支持吗?可以咨询下s3的qps限制和buket分片,能提升读写性能

大佬这个思路确实没想到过,我咨询看看。

ticdc 落文件后续会优化并行写文件,当前单表是单并行的。

可以考虑写本地,然后用脚本刷到 s3 :thinking: ,如果性能实在提不上去的话。

也就是 v5.3.0版本是还不支持多并发Sink S3吗?测试验证的时候调整worker-count参数没有生效

是单表是单线程的,多表之间是并行的。 5.3.0 cdc 有落 file 功能了?这个好像是新出的 而且没 ga 呢。

v5.3.0是支持写S3的,但是到v5.4.0又不支持了。
应该是做了一些重构的操作。我们这边由于集群版本原因,只能使用回v5.3.0

行吧 当前 pitr 用 br 即可,530 不是 lts 版本吧,最好回到主版本中。而且这个功能未 ga ,使用上多测测。

v5.3.0和v5.4.0是LTS版本,目前使用上还是比较稳定的。

主要最近使用CDC场景多了起来,就遇到写S3慢的问题

最新的情况是通过调大 per-table-memory-quota参数为512MB,可以让写S3的QPS峰值从5k提升到10k,但是QPS不够稳定在5k~10之间波动。

产品上单表并行可能还要再等等,目前这个需求的排队不是很理想。感觉可以试试先刷本地 nvme 盘,然后脚本刷 s3,如果有性能要求的话。

高峰有点延迟能接受也无所谓了。

不过如果 ticdc 落 file 是为了做 pitr,推荐用新版本的 br。

我是用的binlog落file做的pitr,恢复演练过几次,没啥问题。

新版本的BR PITR的确能解决我们这个需求。不过线上集群版本都是v5.4,要短时间内升级比较难。

大佬你说的cdc刷本地盘,是cdc写NFS这个来实现吗

基于tidb-server的binlog之前我们也测试和使用过,综合考虑工具的稳定性以及到后面官方的支持情况,主要推的是cdc工具

对。内存刷盘比较快。。。。

了解,多谢大佬耐心解答。
我们之前对比使用NFS和S3,后面统一要求使用S3了。现在先暂时通过调大 per-table-memory-quota参数,来获得同步性能的提升。看来要根本解决写S3的性能问题,还是要升级集群到高版本,再用上BR 的PITR功能或用v6.5以后的TiCDC了。

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。