已经清楚，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来自己消费和路由

https://github.com/pingcap/tidb/issues/57439 对应的表结构发下吧，可能是bug,如果是没解决的bug的话暂时只能绕过了

[image] 看起来是索引数据不一致的问题，可以根据文档进行解决 https://docs.pingcap.com/zh/tidb/stable/troubleshoot-data-inconsistency-errors/#error-8141

点赞，开源社区，友好沟通，而且tidb社区也明确说明了很欢迎大家提代码和文档的相关bug，并会给一定的积分奖励