CDC 延迟非常高如何解决

【 TiDB 使用环境】生产环境
【 TiDB 版本】4.0.13
【遇到的问题:问题现象及影响】
上游tidb 对1个大概3000W数据的表进行了多次的全量数据更新,下游mysql顺序执行 延迟非常大 。有什么好的办法解决吗? 是否可以直接备份上游的表 到下游恢复,但是cdc会重复执行。问题根源应该是上游tidb顺序执行 下面的mysql也是顺序。
【资源配置】
【附件:截图/日志/监控】


[details="摘要"] 此文本将被隐藏 [/details]

延迟高的瓶颈是mysql执行慢吗?

是对一张表所有数据进行全量反复修改吗

是新增了5列数据,然后复制原有5列数据到 新的这5列上。 这么做是因为tidb4.0.13版本不支持双精度进行alter .

这个怎么看呢? 我在mysql上看是一条一条的执行的。

你先看下mysql服务器的负载和io

v6版本可以通过配置 sink uri 参数 transaction-atomicity来控制 TiCDC 是否拆分单表事务。拆分事务可以大幅降低 MySQL sink 同步大事务的延时和内存消耗。

看看是上游还是下游慢

断了吧 mysql吃不消这种复制 手工导入

TiDB CDC 在同步大量数据更新时,可能会出现延迟大的问题,这是由于 TiDB CDC 需要将上游的事务按照原始顺序同步到下游,而下游的 MySQL 可能无法快速处理这些事务
调整 TiDB CDC 的参数,如 per-table-memory-quota, sink.max-txn-row, sink.worker-count 等,以提高 TiDB CDC 的内存和并发能力
调整下游 MySQL 的参数,如 innodb_flush_log_at_trx_commit, sync_binlog, max_allowed_packet 等,以提高 MySQL 的写入性能
如果上游 TiDB 的表结构和数据量允许,您可以考虑使用 BR 工具进行备份和恢复,以减少 TiDB CDC 的同步压力

是一条条执行所以mysql慢 类似于binlog的row模式