TiDB5.0 大字段插入卡死,提示TiKV server is busy,

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】

【概述】 场景 + 问题概述

【应用框架及开发适配业务逻辑】

【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 系统卡死,提示

【业务影响】 系统卡死

【TiDB 版本】 5。0

【附件】 相关日志及监控(https://metricstool.pingcap.com/)

TiDB的行推荐不超6MB,所以对于longtext和blob来说可能不推荐使用。后来从4.0.10开始没有了6MB限制,但在实际使用中(打开集群配置中单行大小等限制)来进行某个字段超过(11MB)的数据行插入时,出现了整表卡死(TiKV server is busy,集群报错是raft同步失败),不得不重启测试集群恢复该表的情况(5.0版本依旧,集群为 2pd 3tikv 3tidb 2tiflash 均为8核16g虚拟机,共用2个磁盘千兆网卡)。但是单个机器部署(1kv 1tidb 1pd)同配置又可以。

虽然业务上我们之后限制了6MB大小单行,但还是想问这种情况历史数据还是时常出现。想请教这是我们自己部署的原因还是因为tidb目前对longtext等字段支持不完善导致的?


若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

在 v4.0.10 ~ v5.0 中,tidb 默认还是有单行大小不超过 6 MB 的限制,不过引入了新的参数 txn-entry-size-limit , 最大支持 120 MB ,但在实际使用中还是需要结合 tikv 层单次写入请求的限制(默认 8MB ,由参数 raft-entry-max-size)来使用,如果业务上有些历史数据无法调整,可以适当调大该参数。

这个问题我们之前也遇到了,除了官方文档提到的两个参数(txn-entry-size-limit&raft-entry-max-size),在我们的实践中,发现还有第三个隐藏参数需要调整:

max-grpc-send-msg-len : 用于设定 grpc 最大消息体大小,截止 2021.07.10 ,该参数未被在文档中提及,属于「隐藏配置项」,时在排查问题时才从官方研发团队获知的一个参数

截止 2021.9.30 我们也遇到了 希望能尽快完善相关文档。