【 TiDB 使用环境】生产环境
【 TiDB 版本】5.4.3
使用grpc订阅cdc，Region数量为2400+，cdc变更量为500w+，所有Region从订阅到收到第一个心跳，总共耗时为20分钟。
请问有什么方法可以优化这个耗时吗？比如调整grpc的参数或者tikv cdc的参数
已经尝试调大
cdc.incremental-scan-concurrency
cdc.incremental-scan-speed-limit
cdc.incremental-scan-threads
三个参数，但没有优化的效果
可以尝试以下方法进行优化：
- 调整TiCDC的参数：您已经尝试调整了
cdc.incremental-scan-concurrency、cdc.incremental-scan-speed-limit和cdc.incremental-scan-threads这三个参数，但没有看到优化效果。除了这些参数，还有一些其他的参数可以尝试调整，例如cdc.region-concurrency和cdc.region-split-check-diff等。您可以根据实际情况逐个尝试调整这些参数，以找到最佳的配置。 - 调整TiKV的参数：TiCDC的性能也受到TiKV的影响，因此可以尝试调整TiKV的参数来提高性能。例如，可以调整
raftstore.apply-pool-size和raftstore.store-pool-size等参数来增加TiKV的并发处理能力。 - 增加TiCDC实例：如果您的TiCDC实例的资源（CPU、内存、网络带宽等）已经达到瓶颈，可以考虑增加TiCDC实例的数量，以提高并发处理能力。您可以在不同的机器上部署多个TiCDC实例，并使用TiCDC的多个实例来订阅不同的Region，以分摊订阅压力。
- 调整网络配置：网络延迟也可能对TiCDC的订阅延迟产生影响。您可以尝试优化网络配置，例如调整网络带宽、减少网络拥塞等，以提高TiCDC的订阅性能。
- 使用TiDB Binlog：如果您的业务场景允许，可以考虑使用TiDB Binlog来替代TiCDC。TiDB Binlog是一种基于日志的增量数据订阅方式，相比TiCDC，它可以提供更低的延迟和更高的吞吐量。您可以根据实际需求评估是否可以使用TiDB Binlog来优化订阅延迟。
通常tikv推送数据不会是性能瓶颈，而是内部处理或同步到下游会比较容易出现瓶颈。
你可以参考我这个场景调优试试。
2 个赞
CDC涉及到源端和目的端，两个性能都要跟上才行，还有网络
cdc集群的配置需要按照推荐配置来
啊？ 不是说cdc性能更好吗？ 后期要下掉 tidb binlog 组件吗?