TiDB CDC性能优化指南：从参数调优到最佳实践

TiDB CDC性能优化指南：从参数调优到最佳实践

引用

CSDN

等

12

来源

1.

https://m.blog.csdn.net/TiDBer/article/details/145068472

2.

https://xie.infoq.cn/article/d58954a26f10591c20010c7a8

3.

https://m.blog.csdn.net/TiDBer/article/details/137277720

4.

https://tidb.net/blog/tag/new-version-features-released

5.

https://tidb.net/blog/b4b41c79

6.

https://www.bookstack.cn/read/tidb-7.1-en/66e5d0ba52ee04f8.md?wd=MQ

7.

https://distsys.cn/u/4

8.

https://cn.pingcap.com/article/post/16591.html

9.

https://cn.pingcap.com/article/post/17584.html

10.

https://cn.pingcap.com/article/post/17188.html

11.

https://asktug.com/t/topic/1026394

12.

https://www.cnblogs.com/apachecn/p/18473528

在使用TiDB Data Change Capture (CDC)进行数据同步时，延迟问题一直是用户关注的重点。本文将从原理、关键参数、监控指标和实际案例等多个维度，为您详细解析如何优化TiDB CDC的性能，降低同步延迟。

TiDB CDC通过监听TiKV的Raft log来捕获数据变更，然后将这些变更数据发送到下游系统。整个过程可以分为三个阶段：

1. Capture阶段：从TiKV获取数据变更
2. Sort阶段：对获取到的数据进行排序
3. Sink阶段：将排序后的数据发送到下游

了解这个基本流程有助于我们理解各个参数的作用和优化方向。

per-table-memory-quota

这个参数控制每个表在排序阶段可使用的最大内存。适当增加该值可以提升处理效率，但需避免因设置过高导致系统资源耗尽。

{
  "sort": {
    "per-table-memory-quota": "2GB"
  }
}

worker-count

调整Sink阶段的并发数，以优化数据写入下游的速度。通过测试找到最佳并发数量，在保证性能的同时避免资源浪费。

{
  "sink": {
    "worker-count": 16
  }
}

max-batch-size 和 max-batch-memory

限制发送到Kafka消息的最大行数和内存使用，平衡处理速度与资源消耗，根据网络状况和下游处理能力进行调整。

{
  "sink": {
    "max-batch-size": 1000,
    "max-batch-memory": "1MB"
  }
}

超时相关参数

如dial-timeout、read-timeout和write-timeout，可根据实际网络环境进行优化。

{
  "sink": {
    "dial-timeout": "5s",
    "read-timeout": "10s",
    "write-timeout": "10s"
  }
}

enable-old-value

开启后记录变更前的数据，对性能有一定影响，按需启用。

{
  "sink": {
    "enable-old-value": true
  }
}

mounter-worker-num 和 sink-worker-num

分别控制Mounter和Sink阶段的并发数，默认为8和16，可通过调整进一步优化性能。

{
  "sort": {
    "mounter-worker-num": 16
  },
  "sink": {
    "sink-worker-num": 32
  }
}

Changefeed checkpoint lag

反映从上游数据变更到下游完成同步的时间差，正常情况下应小于10秒。如果这个值持续增大，说明同步存在瓶颈。

Changefeed resolved ts lag

表示TiCDC内部处理进度与上游的差距，过高可能意味着瓶颈。这个指标可以帮助我们定位问题所在。

QPS

关注同步任务的吞吐量，如达到60k QPS则表明性能较优。

以一个实际的用户案例来说明TiDB CDC同步延迟问题的排查和解决过程。

某用户在使用TiDB 6.5.7版本时，遇到CDC同步报错"Error 1067: Invalid default value for 'column1'"。通过查看changefeed状态和日志，发现是由于应用端修改时区后执行了受时区影响的DDL语句导致的。

{
  "upstream_id": 7429158424764920159,
  "namespace": "default",
  "id": "onemirror-reptask",
  "state": "warning",
  "checkpoint_tso": 454306087227359251,
  "checkpoint_time": "2024-12-01 16:03:08.703",
  "error": {
    "time": "2024-12-01T16:26:23.185248266+08:00",
    "addr": "xxx:8300",
    "code": "CDC:ErrReachMaxTry",
    "message": "[CDC:ErrReachMaxTry]reach maximum try: 20, error: Error 1067: Invalid default value for 'end_time': Error 1067: Invalid default value for 'end_time'"
  }
}

这个案例说明，在实际使用中，CDC任务可能会因为时区等看似无关的因素导致同步失败。因此，在优化性能的同时，也要注意这些细节问题。

1. 硬件升级：提高CPU、内存等硬件配置以支撑更高负载。推荐使用8核16GB以上的配置。

2. 网络优化：减少延迟并保障带宽，特别是在跨地域部署场景中。建议使用专线或高质量的网络连接。

3. 均衡负载：通过增加TiCDC实例分散压力，避免单点过载。推荐至少部署3个TiCDC实例。

4. 合理配置参数：根据实际场景和资源情况，调整上述关键参数。建议在测试环境中充分测试后再应用到生产环境。

5. 监控和告警：建立完善的监控体系，及时发现和处理性能瓶颈。重点关注上述提到的关键指标。

通过以上方法，可以有效降低TiDB CDC的同步延迟，并提升整体性能表现。希望本文能帮助您更好地理解和优化TiDB CDC系统。