Optimization of BR Progress Issues

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

Original topic: br进度问题优化

| username: jaybing926

[TiDB Usage Environment] Production Environment
[TiDB Version] v5.4.3

[Encountered Problem: Phenomenon and Impact]
Is the br backup progress checksum logic now based on the number of tables?
During the checksum, it instantly reaches 90%, then gets stuck at this progress for several hours without any change, and then suddenly completes.

The br tool is one of the commonly used tools for operations and maintenance. I hope the official team can optimize this logic~~ :grinning: :grinning: :grinning: :grinning:

[Attachment: Screenshot/Log/Monitoring]

| username: tidb狂热爱好者 | Original post link

You can also use the TiKV configuration option backup.num-threads or parameter. I changed it to 64 and the speed became very fast. The specific size is related to the number of CPUs in your TiKV. If you have 128 TiKV, you can use 64 cores for backup.

| username: jaybing926 | Original post link

What I mentioned is a progress logic issue, but yours is a speed performance issue. I’m not too concerned about performance; I just want to clarify the progress.

| username: zhaokede | Original post link

Did you encounter a large table? After checking the large table, the progress improved.

| username: jaybing926 | Original post link

Yes.

| username: 这里介绍不了我 | Original post link

Indeed, the backup process feels fast, but the checksum progress is not clearly visible.