Issues Related to Using BR for Data Recovery

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

Original topic: 关于使用BR恢复数据的问题

| username: 泰迪比爱好者

[TiDB Usage Environment] Production Environment / Testing / PoC
[TiDB Version] V7.1.1
[Reproduction Path] What operations were performed when the issue occurred
[Encountered Issue: Issue Phenomenon and Impact]
[Resource Configuration]
[Attachments: Screenshots/Logs/Monitoring]
When using BR for data recovery, due to the large amount of data, the CPU is fully utilized. Is there any way to control this?

| username: Billmay表妹 | Original post link

You can try setting the number of backup threads to a smaller value, such as 4 or 8, to reduce CPU usage.

| username: 大飞哥online | Original post link

You can change this TiKV parameter: backup.num-threads.

| username: 像风一样的男子 | Original post link

The --ratelimit parameter can limit concurrency.

| username: yeminhua | Original post link

Use the TiKV configuration option backup.num-threads or the parameter --ratelimit to limit the speed, or check if the auto-tuning feature is enabled with backup.enable-auto-tune.

| username: 路在何chu | Original post link

The CPU is maxed out. You can only add more CPUs or lower the concurrency during recovery, but this will affect the recovery speed.

| username: zhanggame1 | Original post link

If it’s full, what’s the problem? BR restores the database without providing external services, so it should be fully utilized.