咖啡杯好看

开启可以看这个文档：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…

已经清楚，5M的限制是用在了并发分片上传，但是设置了ratelimit后就无法并发，单独的分片上传没有限制，所以才会出现参数不起作用的情况

[image] [image] 看代码里貌似支持5M的分块上传，大佬们帮忙看看为啥不行，是因为我备份设置了ratelimit了么，还是因为backup.s3-multi-part-size参数确实不起作用了

如果更改MetaFileSize，自己编译会不会有其他风险，或者官方能提供个接口，参数之类的，我想既然有sst-max-size参数，就是为了控制文件大小限制的，那MetaFileSize应该也是个可传参的吧

[image] 查看github发现metafilesize达到128M才会自动切分

2025-08-18 23:35 87588691 s3://backup-data/2025-08-18/backupmeta.datafile.000000001 2025-10-19 22:44 102792275 s3://backup-data/2025-10-19/backupmeta.datafile.000000001 2025-10-22 22:45 103305170 s3://backup-data/2025-10-22/backupmeta.datafile.000000001 2025-10-25 22:47 104377670 s3…

还是不行，没改的时候报错事105M，改成96M报错是110M，改成80M的时候报错是130M了 [2025/11/05 06:28:57.210 +08:00] [INFO] [client.go:943] ["backup range completed"] [range-sn=532] [startKey=7480000000000003335F69800000000000000300] [endKey=7480000000000003335F698000000000000003FB] [take=51.901227ms] [2025/11/05 06:28:57.212 +08:00]…

竟然是tikv的参数，我说在br上没有找到呢，我试下

正常你下游创建表后，直接dm同步就行，因为dm的建表语句是create table if not exists,所以不用特殊处理，你可以拿一个表测试下

那其实也可以使用dumpling,lightning的方式，lightning本身也有路由功能，但是不太清楚你迁移的部分数据有没有冲突的情况

发帖请详细说明相关信息，按发帖提示补充