tikv节点莫名重启

[GreenGuan (袖珍椰子)]

一个kv节点总是莫名其妙的自己跑重启，也没有oom，请问有人碰到过么，报错如下

[ERROR] [] [“assertion failed: slice_buffer->length <= UINT32_MAX”]

[xfworld (魔幻之翼)]

什么版本？

[h5n1]

感觉像是bug，有个tikv 处理数据超4G的问题

[哈喽沃德]

肯定是配置有问题。

[张雨齐0720 (Zhangjig)]

感觉是有问题，具体版本，运行情况等描述一下？

[GreenGuan (袖珍椰子)]

TiDB 版本是 v4.0.9，如果是配置问题，需要确认哪方面的配置？

[spc_monkey (carry@pingcap.com)]

这个现在还是重启吗？

[GreenGuan (袖珍椰子)]

这个报错并重启的现象出现过两次，我认为后期可能遇到的几率比较大，我的版本是 409

[BraveChen (我人傻了)]

坐等大佬解答

[spc_monkey (carry@pingcap.com)]

这是个 已知 bug，这是对应修复的 PR https://github.com/tikv/tikv/pull/10971，在 v4.0.15，v5.0.4，v5.1.2，v5.2.2 及以上版本修复了，
常见 GRPC 发送超过 4GB 消息可能存在以下几种情况

• 如果存在大 region, 可以尝试手工 split region，使用 pd control 命令完成

>> region topsize    //查看 region 大小
>> operator add split-region 1 --policy=approximate     // 将 Region 1 对半拆分成两个 Region，基于粗略估计值
>> operator add split-region 1 --policy=scan            // 将 Region 1 对半拆分成两个 Region，基于精确扫描值

• 如果 tikv.log 日志中同时存在 no valid key found for split ，可能由于 gc 设置时间太长，积累了大量 mvcc key。可以尝试降低 gc 时长

         update mysql.tidb set VARIABLE_VALUE="xxx" where VARIABLE_NAME="tikv_gc_life_time";

[GreenGuan (袖珍椰子)]

昨天又发生了 oom 问题，今天准备升级540