试试调大socket.request.max.bytes，这个kafka侧配置

[image] show config显示的tidb和pd都关闭了，还是有发送

步骤1通过tiup cluster edit-config修改的pd属性，tiup的也已经关闭了，重启集群之后还是有少量信息发送

可以先把gc life time调小点，2天时间有点太久了，看compaction flow越来越大，pending bytes也有点高；另外把auto analyze可以先关闭下，或者把start和end调整到UTC时间的00:00 +0800和07:00 +0800

你看下查询慢的时候，是否正好有写入在更新相同的行，感觉像是读写冲突，可以看下慢的时候的执行计划，rosolvelock是不是等待时间比较久

可以按照下面的方法把tikv-detail的grafana数据导出下，tikv CPU有点高，看下具体哪个部分引起的

查到了，是br备份引起，当前在br checksum阶段，但是官方文档上没有介绍会启动这样一个实例。

找到了，是5.1的bug，https://github.com/pingcap/tidb/issues/30980

GC是一直work的，目前设置了gc life time =60m，并且safe point也正常推进，但是1小时内表上的修改量肯定没有那么大的。 [image]

目前发现是不同的tidb-server上执行计划不同，看了下2台机器上的STATS_HEALTHY的健康程度不同，手动更新了下统计信息，我们再观察下 [image] [image]

dashboard里显示是“前序执行耗时”，代码来执行没有并发更新，理论上没有其他DML阻塞这个更新。

好的，我重新开个帖

自己改下reparo就行，输出到file，tac顺序之后重新管道到tidb就可以回滚了。参考 https://github.com/cenkore/tidbflashback

在v4.0.5版本遇到相同的问题，该如何处理

好的，多谢。我们尽快升级4.0.3+版本

修改之前的表