读写性能的提升，提升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要设置路由规则，并且按需配置写入是否为覆盖写入

线上的活动基本都有参与，特别是mysql与tidb一系列活动，非常有意义，稀罕的就是时间比较忙，线下活动参与的比较少，只参加了AI相关 祝福 TiDB 越做越好，也祝各位 TiDBer 都能身体健康，升职加薪，财富自由

如果只是下线检查的话可以把下线的那台先stop对应的组件，然后机器关机，检查或者换完内存后正常开机就行了，组件会自动拉起，有两点要注意，1.关机的机器不要动磁盘，2.修复内存过程中要保证其他两台机器不要出问题，如果这两点无法保证的话就先扩容一个节点再操作

才发现1024竟然是周五，不加班就算福利了

如果使用nohup备份的注意日志有没有[“received signal to exit”] ，如果有就别用nohup备份，这样就能解决，这个noleader日志告警很有迷惑性

暂时不支持路由配置，目前只能通过写到kafka来自己消费和路由