TiCDC 整体指标
通过以下指标,你可以了解 TiCDC 数据同步的整体情况:
Changefeed checkpoint lag:同步任务上下游数据的进度差,以时间单位秒计算。
如果 TiCDC 消费数据的速度和写入下游的速度能跟上上游的数据变更,该指标将保持在较小的延迟范围内,通常是 10 秒以内。如果 TiCDC 消费数据的速度和写入下游的速度跟不上上游的数据变更,则该指标将持续增长。
该指标增长(即 TiCDC checkpoint lag 增长)的常见原因如下:
- 系统资源不足:如果 TiCDC 系统中的 CPU、内存或磁盘空间不足,可能会导致数据处理速度过慢,从而导致 TiCDC Changefeed checkpoint 过长。
- 网络问题:如果 TiCDC 系统中存在网络中断、延迟或带宽不足的问题,可能会影响数据的传输速度,从而导致 TiCDC Changefeed checkpoint 过长。
- 上游 QPS 过高:如果 TiCDC 系统需要处理的数据量过大,可能会导致数据处理超时,从而导致 TiCDC Changefeed checkpoint 增长,通常一个 TiCDC 节点处理的 QPS 上限为 60K 左右。
- 数据库问题:
- 上游 TiKV 集群
min resolved ts和最新的 PD TSO 差距过大,通常是因为上游写入负载过大,TiKV 无法及时推进 resolved ts 造成。 - 下游数据库写入延迟高导致 TiCDC 无法及时将数据同步到下游。
- 上游 TiKV 集群
Changefeed resolved ts lag:TiCDC 节点内部同步状态与上游的进度差,以时间单位秒计算。如果 TiCDC Changefeed resolved ts lag 值很高,可能意味着 TiCDC 系统的 Puller 或者 Sorter 模块数据处理能力不足,或者可能存在网络延迟或磁盘读写速度慢的问题。在这种情况下,需要采取适当的措施,例如增加 TiCDC 实例数量或优化网络配置,以确保 TiCDC 系统的高效和稳定运行。
The status of changefeeds:Changefeed 各状态的解释。
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




