Manually Restoring Data to a New Cluster Causes Significant Increase in Disk Usage

Translated
1

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: br手动恢复数据到新集群，磁盘使用增加非常多

| username: TiDBer_yyy

[TiDB Usage Environment] Production Environment
[TiDB Version] Both old and new clusters are 5.0.4
[Reproduction Path] BR backup restores data to the new cluster, and the new cluster’s disk space grows significantly, reaching 80%+

image
image1380×162 30.9 KB

Questions

  1. The new cluster’s disk space is insufficient, and temporarily unable to expand the cluster. How should this be handled? Can it be manually compacted? TiKV Control 使用说明 | PingCAP 文档中心

  2. If manual compaction is possible, what impact would directly executing compaction have, such as using up the remaining disk space?

2
| username: Fly-bird | Original post link

Temporary write operations will amplify disk usage, but it will return to normal after recovery.

3
| username: TiDBer_yyy | Original post link

Understood, I get that the disk space is sufficient. I suspect the LSM-tree hasn’t been compacted.

4
| username: TiDBer_yyy | Original post link

Is there a way to speed up the recovery process? Currently, we need to restore data quickly.

5
| username: 昵称想不起来了 | Original post link

Try this for a speed boost? BR 备份与恢复场景示例 | PingCAP 归档文档站

6
| username: xfworld | Original post link

Will BR be restored? We can only wait for now. The new version has made some optimizations to BR’s checksum, which will make it much faster…

7
| username: 大飞哥online | Original post link

The --ratelimit option in br restore limits the maximum speed at which each TiKV executes the restore task (unit: MiB/s).

8
| username: 大飞哥online | Original post link

When restoring with BR, if there are no obvious bottlenecks in TiKV resource usage, you can try increasing the --concurrency parameter (default is 128).