作者：老龚，脉讯在线运维工程师
一、背景
当前核心集群版本为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、感谢 @军军@表妹@社区和群友大佬们的鼎力支持！
希望可以多多搞一些这种官方互助活动，有官方的加持 让很多老版本用户勇敢的迈出这一步~