问一下tidb的br还原是否有可调参数

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】
能否加快还原速度


这是我备份的速度33.3g 还原正好慢十倍。是啥原因哪个参数没调整呢?
备份到s3 从s3还原

这哪里看出来慢了?原来的回复速度多少?

备份速度33g 恢复速度只有2.5g

有啥背景信息吗?你这看不出有啥呀?

从哪里备份?恢复到哪里?

只能说还原速度太慢了 。可能是磁盘不行
+00:00] [INFO] [collector.go:77] [“Full Restore success summary”] [total-ranges=246425] [ranges-succeed=246425] [ranges-failed=0] [split-region=8m29.304639926s] [restore-ranges=143985] [total-take=8h42m23.354499141s] [BackupTS=450047199759040513] [RestoreTS=450051441882038273] [total-kv=51476612568] [total-kv-size=6.522TB] [average-speed=208.1MB/s] [restore-data-size(after-compressed)=1.104TB] [Size=1104033608541]
每分钟还原200M 总共6.5tb

试试下面这个?

从 v8.0.0 起,br 命令行工具新增 --tikv-max-restore-concurrency 参数,用于控制每个 TiKV 节点的最大 download 和 ingest 文件数量。此外,通过调整此参数,可以控制作业队列的最大长度(作业队列的最大长度 = 32 * TiKV 节点数量 * --tikv-max-restore-concurrency),进而控制 BR 节点的内存消耗。通常情况下,--tikv-max-restore-concurrency 会根据集群配置自动调整,无需手动设置。如果通过 Grafana 中的 TiKV-Details > Backup & Import > Import RPC count 监控指标发现 download 文件数量长时间接近于 0,而 ingest 文件数量一直处于上限时,说明 ingest 文件任务存在堆积,并且作业队列已达到最大长度。此时,可以采取以下措施来缓解任务堆积问题:

  • 设置 --ratelimit 参数来限制下载速度,以确保 ingest 文件任务有足够的资源。例如,当任意 TiKV 节点的硬盘吞吐量为 x MiB/s 且下载备份文件的网络带宽大于 x/2 MiB/s,可以设置参数 --ratelimit x/2。如果任意 TiKV 节点的硬盘吞吐量为 x MiB/s 且下载备份文件的网络带宽小于或等于 x/2 MiB/s,可以不设置参数 --ratelimit
  • 调高 --tikv-max-restore-concurrency 来增加作业队列的最大长度。

瓶劲在硬盘还是网速

还原的命令贴一下

是备份本机还是在nfs,s3还是哪里?网络和磁盘性能指标,如果这些都没瓶颈。检查恢复参数设置。比如有大量的region.看看有没有–granularity="coarse-grained"这些设置。

这个关键还得看网络、磁盘性能

从S3还原,要么是网速慢,要么是磁盘写入速度慢