TiDB 6.1.0 升级6.1.7 版本有没有什么坑

🪐 TiDB 技术问题 升级
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】6.1.0
【复现路径】TiDB 6.1.0 升级6.1.7 版本有没有什么坑
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

2

小版本没什么坑，都是bug 修复了

1 个赞
3

6.1.0升级到6.1.7，只是小版本升级，基本上都是修复6.1.X的bug，没什么坑；建议升级之前做测试。

4

好的，感谢

5

bug太多了，最少也搞成7

6

也不能一步到位吧，先升级小版本稳一些吧

7

我们之前也是V6.1，V6.1问题太多了，看现在很多公司都是V6.5、V7.1甚至V7.5了

8

大佬，你们升级了吗

9

除了测试，找出来bug，没有其他的方法。

11

升级后踩坑了，一个ticdc 的任务发消息到kafka没正常恢复，报了这个错

“code”: “CDC:ErrProcessorUnknown”,
“message”: “[CDC:ErrKafkaAsyncSendMessage]kafka async send message failed: kafka: Failed to produce message to topic xxx: write tcp xxx:52344-\u003exxx:9111: write: connection reset by peer”

12

看监控是由于kafka限流影响了

13

往7以上升吧

14

-–
看起来和这个报错是一样的，你在升级之前 6.1.0 的版本并没有报错么？

16

没升级前的6.1.0版本是没报错的

17

看ckafka的监控是限流了，然后ticdc 这边没有重试

18

不是ticdc 任务一启动就报这个错，是跑了1分钟作用才报这个错的，应该是触发了ckafka的限流机制，但是ticdc 6.1.7 版本没自动去重试导致一直在重启

19

如果是限流导致的，那很有可能跟这个变更有关系。6.1.3默认会拆分事务，同步效率有了大幅度的提升，可以继续将 transaction-atomicity设置为table，降低同步速度 :joy:

image
image1075×352 32.9 KB

20

或者就是降低 worker 的并发，减低写入速度。

[mounter]
worker-num = 8
21

好的，我试下，感谢

22

试了改了 worker-num 这个参数没用
transaction-atomicity 这个不支持sink kafka 修改

最后是把partition 改成table后恢复了，看监控改成table 后也限流了，估计是这块有做重试，而partition 为rowid 的没做重试，导致报错