脉讯在线：核心 TiDB 从 5.4 升级到 7.1 集群 CDC 性能翻倍

原文来源：https://tidb.net/blog/4025ea17

作者：老龚，脉讯在线运维工程师

一、背景

当前核心集群版本为 v5.4.3，架构为 cdc 数据接入 kafka 后再消费入库，因为历史数据庞大需要定期清理历史数据导致频繁达到 ticdc 的性能瓶颈出现 cdc_checkpoint_high_delay 告警，而旧版本 cdc 无法过滤清理历史数据的 delete SQL。

升级目的：

• 过滤清理历史数据的 delete sql，避免 cdc_checkpoint_high_delay 告警。

• 当前版本 cdc 的性能有点差实测性能瓶颈为 100+K/minute，升级版本提高 cdc 性能。

注：我们升级的目的主要以 cdc 为核心，TIDB 集群本身的性能并未过多关注。

二、升级过程

本次升级为常规升级，在原集群基础上进行 tiup 在线升级：

• 6 个 KV 节点 17T 左右数据，每个 KV 大概 5 分钟，整个升级时间一共为 35 分钟，后面升级的同学可以做个参考。（这个时间是指执行 upgrade 命令到 successfully 的时间不包括其他检查所用时间）

升级过程很顺利，但升级后遇到了一些问题。

三、升级后遇到的问题

问题 1：数据入库出现大量 1205 报错，写入速度下降明显

描述：

• 集群升级后数据写入出现大量 1205 报错 OperationalError: (1205, u’Lock wait timeout exceeded; try restarting transaction’)，相较之前总体数据写入速度下降很多

• 业务场景：python 消费 kafka 数据写入到 tidb，目前有 24 个消费进程。

• 现在看着好像，启动少数几个消费进程就不会报错，启多了就会，不确定是不是这样

结论：

• 问题本身是代码逻辑问题引起的大量冲突，开发优化了代码（kafka 分区机制）后问题解决。

• 但问题暂未得到合理的解释，一样的代码一样的数据库配置（乐观事务），老版本避免了这问题，而升级后出现了，并且没法通过修改配置规避问题。

详情直达 >> 社区链接

问题 2：cdc 升级后服务中断 15 分钟没数据

描述：

• 升级过程很顺利没有报错，但升级完成后 kafka 没有数据达 15 分钟（kafka 接收 cdc 数据）。

结论：在线升级从这监控看是符合预期的。

• 5.4.3 → 7.1.5 cdc 不支持滚动升级，同步会停止，直到所有的 cdc 都升级完毕才会恢复。

• 升级结束之后 cdc 需要时间进行增量扫然后把之前拉下的数据追上，所以 14:30 之后有一小段时间的数据写入是上升的

详情直达 >> 社区链接

问题 3：cdc 升级后好像自动过滤了 INSERT 语句并且 checkpoint 没变化

描述：

• 升级后引入新版本 ticdc 过滤 sql 规则功能，发现任务好像自动过滤了 INSERT 语句，是有 UPDATE 数据的，很奇怪的问题。

• 反复重试和删除重建 changefeed 任务仍不能解决。

结论：

• 这问题目前还没有完全解决，出过 2 次问题第 1 次是升级了 tiup/cluster 版本解决了。

• 第 2 次出问题后直接恢复到了老版本的配置文件，因为是线上业务没有再继续调试。

• 此问题可能是下面问题 4.1 中问题导致，并不是十分确定，有机会再调试。

详情直达 >> 社区链接

问题 4：其他问题和反馈建议

4.1 tiup update self 升级逻辑问题

描述：

• 执行 tiup tiup list 就相当于安装了 tiup tiup，然后升级 self 就不好用了默认就变成了升级 tiup tiup 而不再升级 tiup。

• 官方是把 tiup 本身也变成了一个组件，但这样容易误导人，还麻烦了~ 建议禁用。

结论：

• 在 tiup server 里 tiup 和 playground、tidb 一样都是作为 coponent 存储没有特殊处理

• 老版本 tiup 按字符串匹配，禁止 tiup install tiup 等 操作，并且 tiup update –self 是更新 ~/.tiup/bin/tiup

• 新版本 tiup （也没那么新，感觉改了快一年了）因为用户有升级 tiup 到指定版本需求，加上当时的一些其他需求。所以最终实现方式是放开 2 提到的限制并增加 tiup link xxx 命令来将 component 的软链接添加到 $PATH. 就是保留源方式下保留了另一种安装升级方式（~/.tiup/bin/tiup → ~/.tiup/components/tiup/vx.x.x/tiup)

• 回到这个用户问题，其实是因为 tiup update –self， tiup update xxx 和 tiup xxx 都复用了一个安装 component 的函数，在第一种场景下跳过检测是否已安装就可以了

• https://github.com/pingcap/tiup/pull/2443
  

详情直达 >> 社区链接

4.2 CDC 滚动升级版本支持问题

描述：

• cdc 滚动升级只有 v6.30 以上版本才开始支持，而文档中并没有体现。有大佬留意到在 630 版本文档里是有提示的。

• 我理解此问题应该添加到任何一个跨此版本的升级文档中，要不很多新手不会意识到 ”cdc630 才开始支持滚动升级这一特性”。

详情直达 >> 社区链接

4.3 br 进度问题优化建议

描述：

• 升级前用 BR 备份工具备份全量数据，备份进度很尴尬。

• checksum 的时候瞬间达到 90%，然后卡在这个进度好几个小时没变化，然后瞬间完成。

• br 工具算是运维常用的工具之一了，希望官方大佬优化下这个逻辑~~

详情直达 >> 社区链接

四、升级成果

1、CDC 性能提升至少 3 倍

经过实测（batch ddl 删数据测试），cdc 3 倍原来的性能并没有引起 cdc_checkpoint_high_delay 告警。

2、引入新版本 CDC 过滤 sql 功能，很大提升了效率

五、感谢！

1、感谢 PINGCAP/TIDB 社区 给我们提供了这么好用的开源软件，真心祝愿社区发展越来越好~

2、感谢 @军军 @表妹 @社区和群友大佬们的鼎力支持！

希望可以多多搞一些这种官方互助活动，有官方的加持 让很多老版本用户勇敢的迈出这一步~