Backup and Restore Database

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

Original topic: br restore db

| username: l940399478

[TiDB Usage Environment] Production Environment
[TiDB Version] v6.5.2
[Encountered Problem: Problem Phenomenon and Impact]
When using br restore db for restoration, can it be used to restore a specific db to an already in-use TiDB cluster that contains other dbs? The restoration won’t affect the other existing dbs online, right? Or can it only be restored to an empty TiDB cluster?

| username: 小龙虾爱大龙虾 | Original post link

You can restore a single database to an existing cluster. As for performance, just pay attention to adjusting parameters to control concurrency.

| username: forever | Original post link

I have encountered the same problem. It seems that the TiDB version is too low. After upgrading to version 4.0.0, the problem is resolved.

| username: wfxxh | Original post link

Restoration is possible, but be mindful of the rate limit.

| username: TiDBer_QYr0vohO | Original post link

Yes, there is a parameter for rate limiting.

| username: WinterLiu | Original post link

The ratelimit parameter can limit the export or import speed.

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

Absolutely, during the recovery process, you can adjust the concurrency (the number of concurrent tasks during the backup or recovery phase) and the ratelimit (the speed limit for each TiKV backup data, in MiB/s) to avoid impacting online business.

| username: 友利奈绪 | Original post link

Sure.

| username: kelvin | Original post link

Sure, just control the rate limiting parameters.

| username: TiDBer_rvITcue9 | Original post link

Sure, just control the rate limiting parameters.

| username: l940399478 | Original post link

However, an error occurred during the recovery:
Error: failed to check task exits: log backup task is running: xxx_pitr, please stop the task before restore, and after PITR operation finished, create log-backup task again and create a full backup on this cluster.
Do I just need to stop the log backup, and after the recovery, restart the log backup?

| username: l940399478 | Original post link

The latest error:
Error: the config ‘new_collations_enabled_on_first_bootstrap’ does not match, upstream: False, downstream: True: [BR:Common:ErrUnknown] internal error
However, I checked the value of new_collations_enabled_on_first_bootstrap in both the old and new clusters through show config, and they are both true.

| username: TiDBer_RjzUpGDL | Original post link

Sure.

| username: 呢莫不爱吃鱼 | Original post link

You can do it this way, just configure the relevant parameters.

| username: yytest | Original post link

In TiDB, the br restore db command is used to restore data using the Backup & Restore (BR) tool. The BR tool is specifically designed for TiDB to efficiently back up and restore large-scale data. Based on your description, you want to restore a specific database (DB) to a TiDB cluster that already contains other databases.

In TiDB v6.5.2, the BR tool supports restoring data to an existing cluster, even if that cluster already has other databases. However, when performing the restore operation, you need to pay attention to the following points to ensure that it does not affect the existing databases:

  1. Isolation: When performing the restore operation, try to choose a time window when the cluster load is low to minimize the impact on other databases.
  2. Concurrency Control: If the amount of data to be restored is large, it may occupy a lot of cluster resources, such as network bandwidth and disk I/O, which could affect the normal operation of other databases in the cluster. You can mitigate this impact by adjusting the concurrency of the restore task.
  3. Permission Management: Ensure that the user performing the restore operation has sufficient permissions and that the restore process does not affect the permission settings of other databases.
  4. Data Consistency: During the restore process, ensure that the restored data remains consistent with the data in other databases in the cluster. For example, if the restored database is related to other databases, ensure the integrity of the related data.
  5. Backup Verification: Before restoring, verify the backup data to ensure its integrity and availability.
  6. Monitoring and Logging: Closely monitor the cluster’s status and logs during the restore process to promptly identify and resolve any issues.

In summary, the BR tool supports restoring a specific DB to a TiDB cluster that already contains other DBs, but it requires careful operation to ensure that the normal operation of other databases in the cluster is not affected. Before performing the actual operation, it is recommended to thoroughly read the official documentation of the BR tool and conduct sufficient testing in a non-production environment. If performing the operation in a production environment, make sure to be well-prepared and monitor the process closely.

| username: Kongdom | Original post link

Yes, but it will indeed cause performance jitter, probably because hardware resources are limited.