这个表的数据量是非常少么,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本身也有路由功能,但是不太清楚你迁移的部分数据有没有冲突的情况
首先要弄清楚是否实时迁移,两个表数据是否有冲突
姑且认为实时迁移的情况下我可以想到的两种办法,
一个是有编程能力的情况,利用cdc同步到kafka中,消费kafka消费,写入到另外的表中,写入的时候是否冲突可以做检测并针对不同的情况处理
一个是没有编程能力的情况,可以利用cdc同步到mysql中,利用dm工具同步到tidb中,注意dm要设置路由规则,并且按需配置写入是否为覆盖写入