Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

br: add description for --granularity #15977

Merged
merged 6 commits into from
Jan 22, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions br/br-snapshot-guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -71,6 +71,8 @@ tiup br restore full --pd "${PD_IP}:2379" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"
```

To address the potential bottleneck issue during the restore when there are too many regions, starting from v7.6.0, BR supports a coarse-grained region shuffling approach. You can enable this method by specifying `--granularity=coarse-grained`.
Oreoxmt marked this conversation as resolved.
Show resolved Hide resolved

During restore, a progress bar is displayed in the terminal as shown below. When the progress bar advances to 100%, the restore task is completed and statistics such as total restore time, average restore speed, and total data size are displayed.

```shell
Expand Down Expand Up @@ -200,6 +202,19 @@ The impact of backup on cluster performance can be reduced by limiting the backu

- During data restore, TiDB tries to fully utilize the TiKV CPU, disk IO, and network bandwidth resources. Therefore, it is recommended to restore the backup data on an empty cluster to avoid affecting the running applications.
- The speed of restoring backup data is much related with the cluster configuration, deployment, and running applications. In internal tests, the restore speed of a single TiKV node can reach 100 MiB/s. The performance and impact of snapshot restore are varied in different user scenarios and should be tested in actual environments.
- Starting from v7.6.0, BR introduces an experimental feature that allows the use of a coarse-grained region shuffling algorithm by specifying the command-line parameter `--granularity=coarse-grained`. Additionally, you can leverage the `--tikv-max-restore-concurrency` option to set the concurrency of download tasks for a single TiKV node, making full use of all resources on each TiKV node to achieve parallel and rapid restore. In practical scenarios, in the case of a large-scale region, the cluster snapshot restore speed can be increased by approximately 10 times. An example of usage is as follows:
Oreoxmt marked this conversation as resolved.
Show resolved Hide resolved

```bash
br restore full \
--pd "${PDIP}:2379" \
--storage "s3://${Bucket}/${Folder}" \
--s3.region "${region}" \
--granularity "coarse-grained" \
--tikv-max-restore-concurrency 128 \
--send-credentials-to-tikv=true \
--log-file restorefull.log
```

Oreoxmt marked this conversation as resolved.
Show resolved Hide resolved

## See also

Expand Down
Loading