可以用tcpdump抓下包看看是慢还是确实没推进，之前也遇到过大量删除会有这个现象，抓包后发现delete语句在推进，只是慢

加过，两天吧，尽量选择业务低峰期加

对应的配置信息手动拉取文件可以拉取下来么

oss的信息配置的不对吧，明显链接不上啊，看下配置和权限

ok,通信有问题那正常现象，目前使用7.5.4的版本比较稳定的,如果升级也可以考虑8.5，性能会更好

display下，看下所有tikv的状态，是不是执行过缩容操作

是一瞬间的变化，还是一直变为0，最好提供下拓扑，日志，监控，还有版本

是不是开启了fast ddl但是fast ddl的还是用的默认路径/tmp

tikv竟然还有一个活的，这比较意外啊，先尝试下能不能正常扩容tikv,如果不能正常扩容tikv再考虑unsafe recover

携手奔赴下一个十年！

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。

目前的解法是重新编译br,使meta大小可以配置，暂时没有其他办法

咖啡杯好看

开启可以看这个文档：https://docs.pingcap.com/zh/tidb/v7.5/dev-guide-use-follower-read/#开启-follower-read

貌似是已知bug,https://github.com/pingcap/tidb/commit/aff0c3693f11dacd68525423af9d7187a45b9a82

这个表的数据量是非常少么，analyze的执行时间段配置是什么样的,show analyze status有失败的任务么

看起来swap是不是还开着呢，内存占用满了后开始走swap，性能就会急剧下降，机器配置是什么样的，tidb,pd,tikv的内存相关的参数都什么样,如果都是默认设置的话，你这种混布场景内存是会超的

看报错像是磁盘空间满了，有磁盘空间满的情况吧，检查下各节点的磁盘空间，看display的情况pd状态是正常的

读写性能的提升，提升point_get的速度，大查询的调度尽量不影响整体性能