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

[tidb狂热爱好者]

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

[tidb狂热爱好者]

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

[Kamner]

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

[tidb狂热爱好者]

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

[Billmay表妹 (表妹)]

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

[Billmay表妹 (表妹)]

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

[tidb狂热爱好者]

只能说还原速度太慢了 。可能是磁盘不行
+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

[MrSylar]

试试下面这个？

从 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 来增加作业队列的最大长度。

[zhaokede]

瓶劲在硬盘还是网速

[Miracle]

还原的命令贴一下

[mono (Hacker 3 Lu Tkd Re)]

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

[TiDBer_QYr0vohO]

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

[WinterLiu]

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