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

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的速度，大查询的调度尽量不影响整体性能

方法二有误，因为metafile走的是另一套备份逻辑

因为我用的是7.5.4，在不考虑更改tikv本身region的大小下，观察源码发现共有两种解法 方法一： 更改 MetaFileSize 小于 100 M，重新编译br,进行备份，这个已经测试成功 [image] 方法二： 观察源码发现，v7.5.4，硬编码了分块上传的块大小为 5M，但是这个 5M 只有在 option.Concurrency > 1 的情况才起作用，而我的备份设置了ratelimit,ratelimit 与 option.Concurrency 是互斥的，只要设置了ratelimit就是单线程备份，所以这个5M的分块无法限制，第二种方法就是去掉ratelimi…