已经清楚,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.修复内存过程中要保证其他两台机器不要出问题,如果这两点无法保证的话就先扩容一个节点再操作
如果使用nohup备份的注意日志有没有[“received signal to exit”] ,如果有就别用nohup备份,这样就能解决,这个noleader日志告警很有迷惑性
暂时不支持路由配置,目前只能通过写到kafka来自己消费和路由
点赞,开源社区,友好沟通,而且tidb社区也明确说明了很欢迎大家提代码和文档的相关bug,并会给一定的积分奖励