| title | summary | aliases | |
|---|---|---|---|
RESTORE | TiDB SQL Statement Reference |
An overview of the usage of RESTORE for the TiDB database. |
|
This statement performs a distributed restore from a backup archive previously produced by a BACKUP statement.
Warning:
- This feature is experimental. It is not recommended that you use it in the production environment. This feature might be changed or removed without prior notice. If you find a bug, you can report an issue on GitHub.
- This feature is not available on TiDB Serverless clusters.
The RESTORE statement uses the same engine as the BR tool, except that the restore process is driven by TiDB itself rather than a separate BR tool. All benefits and caveats of BR also apply here. In particular, RESTORE is currently not ACID-compliant. Before running RESTORE, ensure that the following requirements are met:
- The cluster is "offline", and the current TiDB session is the only active SQL connection to access all tables being restored.
- When a full restore is being performed, the tables being restored should not already exist, because existing data might be overridden and causes inconsistency between the data and indices.
- When an incremental restore is being performed, the tables should be at the exact same state as the
LAST_BACKUPtimestamp when the backup is created.
Running RESTORE requires either the RESTORE_ADMIN or SUPER privilege. Additionally, both the TiDB node executing the restore and all TiKV nodes in the cluster must have read permission from the destination.
The RESTORE statement is blocking, and will finish only after the entire restore task is finished, failed, or canceled. A long-lasting connection should be prepared for running RESTORE. The task can be canceled using the KILL TIDB QUERY statement.
Only one BACKUP and RESTORE task can be executed at a time. If a BACKUP or RESTORE task is already running on the same TiDB server, the new RESTORE execution will wait until all previous tasks are done.
RESTORE can only be used with "tikv" storage engine. Using RESTORE with the "unistore" engine will fail.
RestoreStmt ::=
"RESTORE" BRIETables "FROM" stringLit RestoreOption*
BRIETables ::=
"DATABASE" ( '*' | DBName (',' DBName)* )
| "TABLE" TableNameList
RestoreOption ::=
"CHECKSUM_CONCURRENCY" '='? LengthNum
| "CONCURRENCY" '='? LengthNum
| "CHECKSUM" '='? Boolean
| "LOAD_STATS" '='? Boolean
| "RATE_LIMIT" '='? LengthNum "MB" '/' "SECOND"
| "SEND_CREDENTIALS_TO_TIKV" '='? Boolean
| "WAIT_TIFLASH_READY" '='? Boolean
| "WITH_SYS_TABLE" '='? Boolean
Boolean ::=
NUM | "TRUE" | "FALSE"
{{< copyable "sql" >}}
RESTORE DATABASE * FROM 'local:///mnt/backup/2020/04/';+------------------------------+-----------+----------+---------------------+---------------------+
| Destination | Size | BackupTS | Queue Time | Execution Time |
+------------------------------+-----------+----------+---------------------+---------------------+
| local:///mnt/backup/2020/04/ | 248665063 | 0 | 2020-04-21 17:16:55 | 2020-04-21 17:16:55 |
+------------------------------+-----------+----------+---------------------+---------------------+
1 row in set (28.961 sec)In the example above, all data is restored from a backup archive at the local filesystem. The data is read as SST files from the /mnt/backup/2020/04/ directories distributed among all TiDB and TiKV nodes.
The first row of the result above is described as follows:
| Column | Description |
|---|---|
Destination |
The destination URL to read from |
Size |
The total size of the backup archive, in bytes |
BackupTS |
(not used) |
Queue Time |
The timestamp (in current time zone) when the RESTORE task was queued. |
Execution Time |
The timestamp (in current time zone) when the RESTORE task starts to run. |
You can specify which databases or tables to restore. If some databases or tables are missing from the backup archive, they will be ignored, and thus RESTORE would complete without doing anything.
{{< copyable "sql" >}}
RESTORE DATABASE `test` FROM 'local:///mnt/backup/2020/04/';{{< copyable "sql" >}}
RESTORE TABLE `test`.`sbtest01`, `test`.`sbtest02` FROM 'local:///mnt/backup/2020/04/';BR supports restoring data from S3 or GCS:
{{< copyable "sql" >}}
RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-05/';The URL syntax is further explained in URI Formats of External Storage Services.
The URL syntax is further explained in external storage URI.
When running on cloud environment where credentials should not be distributed, set the SEND_CREDENTIALS_TO_TIKV option to FALSE:
{{< copyable "sql" >}}
RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-05/'
SEND_CREDENTIALS_TO_TIKV = FALSE;Use RATE_LIMIT to limit the average download speed per TiKV node to reduce network bandwidth.
Before the restore is completed, RESTORE would perform a checksum against the data in the backup files to verify correctness by default. The default concurrency for checksum tasks on a single table is 4, which you can adjust using the CHECKSUM_CONCURRENCY parameter. If you are confident that the data verification is unnecessary, you can disable the check by setting the CHECKSUM parameter to FALSE.
If statistics have been backed up, they are restored by default during the restore. If you do not need to restore the statistics, you can set the LOAD_STATS parameter to FALSE.
System privilege tables are restored by default. If you do not need to restore system privilege tables, you can set the WITH_SYS_TABLE parameter to FALSE.
System privilege tables are restored by default. If you do not need to restore system privilege tables, you can set the WITH_SYS_TABLE parameter to FALSE.
By default, the restore task does not wait for TiFlash replicas to be fully created before completing. If you need the restore task to wait, you can set the WAIT_TIFLASH_READY parameter to TRUE.
{{< copyable "sql" >}}
RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-06/'
RATE_LIMIT = 120 MB/SECOND
CONCURRENCY = 64
CHECKSUM = FALSE;There is no special syntax to perform incremental restore. TiDB will recognize whether the backup archive is full or incremental and take appropriate action. You only need to apply each incremental restore in correct order.
For instance, if a backup task is created as follows:
{{< copyable "sql" >}}
BACKUP DATABASE `test` TO 's3://example-bucket/full-backup' SNAPSHOT = 413612900352000;
BACKUP DATABASE `test` TO 's3://example-bucket/inc-backup-1' SNAPSHOT = 414971854848000 LAST_BACKUP = 413612900352000;
BACKUP DATABASE `test` TO 's3://example-bucket/inc-backup-2' SNAPSHOT = 416353458585600 LAST_BACKUP = 414971854848000;then the same order should be applied in the restore:
{{< copyable "sql" >}}
RESTORE DATABASE * FROM 's3://example-bucket/full-backup';
RESTORE DATABASE * FROM 's3://example-bucket/inc-backup-1';
RESTORE DATABASE * FROM 's3://example-bucket/inc-backup-2';This statement is a TiDB extension to MySQL syntax.