关于 TiCDC 同步瓶颈问题

[Mwkk (Ti D Ber A Cla Yr Lb)]

【TiDB 使用环境】生产环境 /测试/ Poc
【TiDB 版本】
【操作系统】
【部署方式】云上部署（什么云）/机器部署（什么机器配置、什么硬盘）
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】

我们有一个用 TiCDC 同步的主备集群，最近延迟一直很高，从监控上看 puller 的数量远大于 sorter 的数量，已经调整了 sorter.cache-size-in-mb 为256 M ，最近看日志有出现提示 flushLog blocking too long, the redo manager may be stuck 报错，想问一下2个问题，应该从哪里确定现在的瓶颈点，另外从集群只是为了业务大量数据导出同步用，我是否可以关闭 主集群的 redo ，直接将 sink-url 加 start ts 写为 下游 TiDB集群和 checkpoint 时间 创建 changefeed 同步流？

[像风一样的男子]

几个cdc节点啊，puller output events/s 监控能到多少？

[Mwkk (Ti D Ber A Cla Yr Lb)]

6节点，但是看监控基本上只有一个节点的 cdc 负载比较高，puller output events/s 监控大概17W

[像风一样的男子]

Sink - Transaction Sink里 Full Flush Duration的延迟高吗？

[Mwkk (Ti D Ber A Cla Yr Lb)]

基本在128ms 左右

[像风一样的男子]

那就排除下游写入慢
sorter output events这个指标能到多少？是否和puller output events/s差很多？

[Mwkk (Ti D Ber A Cla Yr Lb)]

最高4W多，是差很多

[像风一样的男子]

你用cdc cli changefeed query 查下cdc任务的sort_engine使用的什么引擎。
我怀疑你是低版本升级上来的还是默认用的 Unified Sorter排序，这个是用cdc本地服务器磁盘缓存数据的，非常吃硬盘。

[Mwkk (Ti D Ber A Cla Yr Lb)]

   "sink": {
      "protocol": "",
      "schema_registry": "",
      "csv": {
        "delimiter": ",",
        "quote": "\"",
        "null": "\\N",
        "include_commit_ts": false,
        "binary_encoding_method": "base64"
      },
      "column_selectors": null,
      "transaction_atomicity": "",
      "encoder_concurrency": 16,
      "terminator": "\r\n",
      "date_separator": "day",
      "enable_partition_separator": true,
      "file_index_digit": 0,
      "enable_kafka_sink_v2": false,
      "only_output_updated_columns": null,
      "content_compatible": null,
      "advance_timeout": 150
    },

[WalterWj (王军 - PingCAP)]

redo 盘的问题，换了就好了。