diff --git a/TOC.md b/TOC.md index 79f5e0803e51..050038cd3df2 100644 --- a/TOC.md +++ b/TOC.md @@ -63,6 +63,7 @@ + 使用 BR 工具（推荐） + [使用 BR 进行备份与恢复](/br/backup-and-restore-tool.md) + [BR 备份与恢复场景示例](/br/backup-and-restore-use-cases.md) + + [BR 存储](/br/backup-and-restore-storages.md) + [使用 Dumpling 和 TiDB Lightning 进行备份与恢复（推荐）](/backup-and-restore-using-dumpling-lightning.md) + [使用 Mydumper 和 TiDB Lightning 进行备份与恢复](/backup-and-restore-using-mydumper-lightning.md) + [读取历史数据](/read-historical-data.md) @@ -243,6 +244,7 @@ - [`ALTER TABLE`](/sql-statements/sql-statement-alter-table.md) - [`ALTER USER`](/sql-statements/sql-statement-alter-user.md) - [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md) + - [`BACKUP`](/sql-statements/sql-statement-backup.md) - [`BEGIN`](/sql-statements/sql-statement-begin.md) - [`CHANGE COLUMN`](/sql-statements/sql-statement-change-column.md) - [`CHANGE DRAINER`](/sql-statements/sql-statement-change-drainer.md) @@ -288,6 +290,7 @@ - [`RENAME INDEX`](/sql-statements/sql-statement-rename-index.md) - [`RENAME TABLE`](/sql-statements/sql-statement-rename-table.md) - [`REPLACE`](/sql-statements/sql-statement-replace.md) + - [`RESTORE`](/sql-statements/sql-statement-restore.md) - [`REVOKE `](/sql-statements/sql-statement-revoke-privileges.md) - [`ROLLBACK`](/sql-statements/sql-statement-rollback.md) - [`SELECT`](/sql-statements/sql-statement-select.md) @@ -296,6 +299,7 @@ - [`SET ROLE`](/sql-statements/sql-statement-set-role.md) - [`SET TRANSACTION`](/sql-statements/sql-statement-set-transaction.md) - [`SET [GLOBAL|SESSION] `](/sql-statements/sql-statement-set-variable.md) + - [`SHOW [BACKUPS|RESTORES]`](/sql-statements/sql-statement-show-backups.md) - [`SHOW ANALYZE STATUS`](/sql-statements/sql-statement-show-analyze-status.md) - [`SHOW BINDINGS`](/sql-statements/sql-statement-show-bindings.md) - [`SHOW BUILTINS`](/sql-statements/sql-statement-show-builtins.md) diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md new file mode 100644 index 000000000000..59aa6552e0ee --- /dev/null +++ b/br/backup-and-restore-storages.md @@ -0,0 +1,81 @@ +--- +title: BR 存储 +summary: 了解 BR 中所用存储服务的 URL 格式。 +--- + +# BR 存储 + +Backup & Restore (BR) 支持在本地文件系统、Amazon S3 和 Google Cloud Storage (GCS) 上读写数据。通过传入 BR 的 `--storage` 参数中的不同 URL scheme，可以区分不同的存储方式。 + +## Scheme + +BR 支持以下存储服务： + +| 服务 | Scheme | 示例 | +|---------|---------|-------------| +| 本地文件系统（分布在各节点上） | local | `local:///path/to/dest/` | +| Amazon S3 及其他兼容 S3 的服务 | s3 | `s3://bucket-name/prefix/of/dest/` | +| GCS | gcs, gs | `gcs://bucket-name/prefix/of/dest/` | +| 不写入任何存储（仅作为基准测试） | noop | `noop://` | + +## 参数 + +S3 和 GCS 等云存储有时需要额外的连接配置，你可以为这类配置指定参数。例如： + +{{< copyable "shell-regular" >}} + +```shell +./br backup full -u 127.0.0.1:2379 -s 's3://bucket-name/prefix?region=us-west-2' +``` + +### S3 参数 + +| 参数 | 描述 | +|----------:|---------| +| `access-key` | 访问密钥 | +| `secret-access-key` | secret 访问密钥 | +| `region` | Amazon S3 服务区域（默认为 `us-east-1`） | +| `use-accelerate-endpoint` | 是否在 Amazon S3 上使用加速端点（默认为 `false`） | +| `endpoint` | S3 兼容服务自定义端点的 URL（例如 `https://s3.example.com/`）| +| `force-path-style` | 使用 path-style，而不是 virtual-hosted style（默认为 `false`） | +| `storage-class` | 上传对象的存储类别（例如 `STANDARD`、`STANDARD_IA`） | +| `sse` | 用于加密上传的服务器端加密算法（可以设置为空，`AES256` 或 `aws:kms`） | +| `sse-kms-key-id` | 如果 `sse` 设置为 `aws:kms`，则使用该参数指定 KMS ID | +| `acl` | 上传对象的 canned ACL（例如，`private`、`authenticated-read`） | + +> **注意：** +> +> 不建议在存储 URL 中直接传递访问密钥和 secret 访问密钥，因为这些密钥是明文记录的。BR 尝试按照以下顺序从环境中推断这些密钥： + +1. `$AWS_ACCESS_KEY_ID` 和 `$AWS_SECRET_ACCESS_KEY` 环境变量。 +2. `$AWS_ACCESS_KEY` 和 `$AWS_SECRET_KEY` 环境变量。 +3. BR 节点上的共享凭证文件，路径由 `$AWS_SHARED_CREDENTIALS_FILE` 环境变量指定。 +4. BR 节点上的共享凭证文件，路径为 `~/.aws/credentials`。 +5. 当前 Amazon EC2 容器的 IAM 角色。 +6. 当前 Amazon ECS 任务的 IAM 角色。 + +### GCS 参数 + +| 参数 | 描述 | +|----------:|---------| +| `credentials-file` | TiDB 节点上的凭证 JSON 文件的路径 | +| `storage-class` | 上传对象的存储类别（例如 `STANDARD`、`COLDLINE`） | +| `predefined-acl` | 上传对象的预定义 ACL（例如 `private`、`project-private` | + +如果没有指定 `credentials-file`，BR 尝试按照以下顺序从环境中推断出凭证： + +1. BR 节点上位于 `$GOOGLE_APPLICATION_CREDENTIALS` 环境变量所指定路径的文件内容。 +2. BR 节点上位于 `~/.config/gcloud/application_default_credentials.json` 的文件内容。 +3. 在 GCE 或 GAE 中运行时，从元数据服务器中获取的凭证。 + +## 向 TiKV 发送凭证 + +在默认情况下，使用 S3 和 GCS 存储时，BR 会将凭证发送到每个 TiKV 节点，以减少设置的复杂性。 + +但是，这个操作不适合云端环境，因为每个节点都有自己的角色和权限。在这种情况下，你需要用 `--send-credentials-to-tikv=false`（或简写为 `-c=0`）来禁止发送凭证： + +{{< copyable "shell-regular" >}} + +```shell +./br backup full -c=0 -u pd-service:2379 -s 's3://bucket-name/prefix' +``` diff --git a/media/sqlgram/BackupOption.png b/media/sqlgram/BackupOption.png new file mode 100644 index 000000000000..4425d81c996e Binary files /dev/null and b/media/sqlgram/BackupOption.png differ diff --git a/media/sqlgram/BackupStmt.png b/media/sqlgram/BackupStmt.png new file mode 100644 index 000000000000..5ffa691835a7 Binary files /dev/null and b/media/sqlgram/BackupStmt.png differ diff --git a/media/sqlgram/BackupTSO.png b/media/sqlgram/BackupTSO.png new file mode 100644 index 000000000000..29ea0bf28a54 Binary files /dev/null and b/media/sqlgram/BackupTSO.png differ diff --git a/media/sqlgram/RestoreOption.png b/media/sqlgram/RestoreOption.png new file mode 100644 index 000000000000..8ff807478df1 Binary files /dev/null and b/media/sqlgram/RestoreOption.png differ diff --git a/media/sqlgram/RestoreStmt.png b/media/sqlgram/RestoreStmt.png new file mode 100644 index 000000000000..7fae5bc1152b Binary files /dev/null and b/media/sqlgram/RestoreStmt.png differ diff --git a/media/sqlgram/ShowBRIEStmt.png b/media/sqlgram/ShowBRIEStmt.png new file mode 100644 index 000000000000..651e03a67802 Binary files /dev/null and b/media/sqlgram/ShowBRIEStmt.png differ diff --git a/media/sqlgram/ShowLikeOrWhereOpt.png b/media/sqlgram/ShowLikeOrWhereOpt.png index c1ec7efaf56a..f68b2d4c1a59 100644 Binary files a/media/sqlgram/ShowLikeOrWhereOpt.png and b/media/sqlgram/ShowLikeOrWhereOpt.png differ diff --git a/sql-statements/sql-statement-backup.md b/sql-statements/sql-statement-backup.md new file mode 100644 index 000000000000..61dd7a8801ab --- /dev/null +++ b/sql-statements/sql-statement-backup.md @@ -0,0 +1,185 @@ +--- +title: BACKUP +summary: TiDB 数据库中 BACKUP 的使用概况。 +--- + +# BACKUP + +`BACKUP` 语句用于对 TiDB 集群执行分布式备份操作。 + +`BACKUP` 语句使用的引擎与 [BR](/br/backup-and-restore-use-cases.md) 相同，但备份过程是由 TiDB 本身驱动，而非单独的 BR 工具。BR 工具的优势和警告也适用于 `BACKUP` 语句。 + +执行 `BACKUP` 需要 `SUPER` 权限。此外，执行备份的 TiDB 节点和集群中的所有 TiKV 节点都必须有对目标存储的读或写权限。 + +`BACKUP` 语句开始执行后将会加锁，直到整个备份任务完成、失败或取消。因此，执行 `BACKUP` 时需要准备一个持久的连接。如需取消任务，可执行 [`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md) 语句。 + +一次只能执行一个 `BACKUP` 和 [`RESTORE`](/sql-statements/sql-statement-restore.md) 任务。如果 TiDB server 上已经在执行一个 `BACKUP` 或 `RESTORE` 语句，新的 `BACKUP` 将等待前面所有的任务完成后再执行。 + +## 语法图 + +**BackupStmt:** + +![BackupStmt](/media/sqlgram/BackupStmt.png) + +**BRIETables:** + +![BRIETables](/media/sqlgram/BRIETables.png) + +**BackupOption:** + +![BackupOption](/media/sqlgram/BackupOption.png) + +**Boolean:** + +![Boolean](/media/sqlgram/Boolean.png) + +**BackupTSO:** + +![BackupTSO](/media/sqlgram/BackupTSO.png) + +## 示例 + +### 备份数据库 + +{{< copyable "sql" >}} + +```sql +BACKUP DATABASE `test` TO 'local:///mnt/backup/2020/04/'; +``` + +```sql ++------------------------------+-----------+-----------------+---------------------+---------------------+ +| Destination | Size | BackupTS | Queue Time | Execution Time | ++------------------------------+-----------+-----------------+---------------------+---------------------+ +| local:///mnt/backup/2020/04/ | 248665063 | 416099531454472 | 2020-04-12 23:09:48 | 2020-04-12 23:09:48 | ++------------------------------+-----------+-----------------+---------------------+---------------------+ +1 row in set (58.453 sec) +``` + +上述示例中，`test` 数据库被备份到本地，数据以 SST 文件的形式存储在分布于所有 TiDB 和 TiKV 节点的 `/mnt/backup/2020/04/` 目录中。 + +输出结果的第一行描述如下： + +| 列名 | 描述 | +| :-------- | :--------- | +| `Destination` | 目标存储的 URL | +| `Size` | 备份文件的总大小，单位为字节 | +| `BackupTS` | 创建备份时的快照 TSO（用于[增量备份](#增量备份)） | +| `Queue Time` | `BACKUP` 任务开始排队的时间戳（当前时区） | +| `Execution Time` | `BACKUP` 任务开始执行的时间戳（当前时区） | + +### 备份表 + +{{< copyable "sql" >}} + +```sql +BACKUP TABLE `test`.`sbtest01` TO 'local:///mnt/backup/sbtest01/'; +``` + +{{< copyable "sql" >}} + +```sql +BACKUP TABLE sbtest02, sbtest03, sbtest04 TO 'local:///mnt/backup/sbtest/'; +``` + +### 备份集群 + +{{< copyable "sql" >}} + +```sql +BACKUP DATABASE * TO 'local:///mnt/backup/full/'; +``` + +注意，备份中不包含系统表 (`mysql.*`、`INFORMATION_SCHEMA.*`、`PERFORMANCE_SCHEMA.*` 等)。 + +### 远端存储 + +BR 支持备份数据到 Amazon S3 或 Google Cloud Storage (GCS)： + +{{< copyable "sql" >}} + +```sql +BACKUP DATABASE `test` TO 's3://example-bucket-2020/backup-05/?region=us-west-2'; +``` + +有关详细的 URL 语法，见 [BR 存储](/br/backup-and-restore-storages.md)。 + +当运行在云环境中时，不能分发凭证，可设置 `SEND_CREDENTIALS_TO_TIKV` 选项为 `FALSE`： + +{{< copyable "sql" >}} + +```sql +BACKUP DATABASE `test` TO 's3://example-bucket-2020/backup-05/?region=us-west-2' + SEND_CREDENTIALS_TO_TIKV = FALSE; +``` + +### 性能调优 + +如果你需要减少网络带宽占用，可以通过 `RATE_LIMIT` 来限制每个 TiKV 节点的平均上传速度。 + +默认情况下，每个 TiKV 节点上运行 4 个备份线程。可以通过 `CONCURRENCY` 选项来调整这个值。 + +在备份完成之前，`BACKUP` 将对集群上的数据进行校验，以验证数据的正确性。如果你确信无需进行校验，可以通过 `CHECKSUM` 选项禁用这一步骤。 + +{{< copyable "sql" >}} + +```sql +BACKUP DATABASE `test` TO 's3://example-bucket-2020/backup-06/' + RATE_LIMIT = 120 MB/SECOND + CONCURRENCY = 8 + CHECKSUM = FALSE; +``` + +### 快照 + +可以指定一个时间戳、TSO 或相对时间，来备份历史数据。 + +{{< copyable "sql" >}} + +```sql +-- 相对时间 +BACKUP DATABASE `test` TO 'local:///mnt/backup/hist01' + SNAPSHOT = 36 HOUR AGO; +-- 时间戳（当前时区） +BACKUP DATABASE `test` TO 'local:///mnt/backup/hist02' + SNAPSHOT = '2020-04-01 12:00:00'; +-- TSO +BACKUP DATABASE `test` TO 'local:///mnt/backup/hist03' + SNAPSHOT = 415685305958400; +``` + +对于相对时间，支持以下时间单位： + +* MICROSECOND（微秒） +* SECOND（秒） +* MINUTE（分钟） +* HOUR（小时） +* DAY（天） +* WEEK（周） + +注意，相对时间的单位遵循 SQL 标准，永远使用单数。 + +### 增量备份 + +提供 `LAST_BACKUP` 选项，只备份从上一次备份到当前快照之间的增量数据。 + +{{< copyable "sql" >}} + +```sql +-- 时间戳（当前时区） +BACKUP DATABASE `test` TO 'local:///mnt/backup/hist02' + LAST_BACKUP = '2020-04-01 12:00:00'; + +-- TSO +BACKUP DATABASE `test` TO 'local:///mnt/backup/hist03' + LAST_BACKUP = 415685305958400; +``` + +## MySQL 兼容性 + +该语句是 TiDB 对 MySQL 语法的扩展。 + +## 另请参阅 + +* [RESTORE](/sql-statements/sql-statement-restore.md) +* [SHOW BACKUPS](/sql-statements/sql-statement-show-backups.md) diff --git a/sql-statements/sql-statement-restore.md b/sql-statements/sql-statement-restore.md new file mode 100644 index 000000000000..6bc1bf8e015c --- /dev/null +++ b/sql-statements/sql-statement-restore.md @@ -0,0 +1,160 @@ +--- +title: RESTORE +summary: TiDB 数据库中 RESTORE 的使用概况。 +--- + +# RESTORE + +`RESTORE` 语句用于执行分布式恢复，把 [`BACKUP` 语句](/sql-statements/sql-statement-backup.md)生成的备份文件恢复到 TiDB 集群中。 + +`RESTORE` 语句使用的引擎与 [BR](/br/backup-and-restore-use-cases.md) 相同，但恢复过程是由 TiDB 本身驱动，而非单独的 BR 工具。BR 工具的优势和警告也适用于 `RESTORE` 语句。需要注意的是，**`RESTORE` 语句目前不遵循 ACID 原则**。 + +执行 `RESTORE` 语句前，确保集群已满足以下要求： + +* 集群处于“下线”状态，当前的 TiDB 会话是唯一在访问待恢复表的活跃 SQL 连接。 +* 执行全量恢复时，确保即将恢复的表不存在于集群中，因为现有的数据可能被覆盖，从而导致数据与索引不一致。 +* 执行增量恢复时，表的状态应该与创建备份时 `LAST_BACKUP` 时间戳的状态完全一致。 + +执行 `RESTORE` 需要 `SUPER` 权限。此外，执行恢复操作的 TiDB 节点和集群中的所有 TiKV 节点都必须有对目标存储的读权限。 + +`RESTORE` 语句开始执行后将会加锁，直到整个恢复任务完成、失败或取消。因此，执行 `RESTORE` 时需要准备一个持久的连接。如需取消任务，可执行 [`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md) 语句。 + +一次只能执行一个 `BACKUP` 和 `RESTORE` 任务。如果 TiDB server 上已经在执行一个 `BACKUP` 或 `RESTORE` 语句，新的 `RESTORE` 将等待前面所有的任务完成后再执行。 + +`RESTORE` 只能在 "tikv" 存储引擎上使用，如果使用 "mocktikv" 存储引擎，`RESTORE` 操作会失败。 + +## 语法图 + +**RestoreStmt:** + +![RestoreStmt](/media/sqlgram/RestoreStmt.png) + +**BRIETables:** + +![BRIETables](/media/sqlgram/BRIETables.png) + +**RestoreOption:** + +![RestoreOption](/media/sqlgram/RestoreOption.png) + +**Boolean:** + +![Boolean](/media/sqlgram/Boolean.png) + +## 示例 + +### 从备份文件恢复 + +{{< copyable "sql" >}} + +```sql +RESTORE DATABASE * FROM 'local:///mnt/backup/2020/04/'; +``` + +```sql ++------------------------------+-----------+----------+---------------------+---------------------+ +| 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) +``` + +上述示例中，所有数据均从本地的备份文件中恢复到集群中。`RESTORE` 从 SST 文件里读取数据，SST 文件存储在所有 TiDB 和 TiKV 节点的 `/mnt/backup/2020/04/` 目录下。 + +输出结果的第一行描述如下： + +| 列名 | 描述 | +| :-------- | :--------- | +| `Destination` | 读取的目标存储 URL | +| `Size` | 备份文件的总大小，单位为字节 | +| `BackupTS` | 不适用 | +| `Queue Time` | `RESTORE` 任务开始排队的时间戳（当前时区） | +| `Execution Time` | `RESTORE` 任务开始执行的时间戳（当前时区） | + +### 部分恢复 + +你可以指定恢复部分数据库或部分表数据。如果备份文件中缺失了某些数据库或表，缺失的部分将被忽略。此时，`RESTORE` 语句不进行任何操作即完成执行。 + +{{< copyable "sql" >}} + +```sql +RESTORE DATABASE `test` FROM 'local:///mnt/backup/2020/04/'; +``` + +{{< copyable "sql" >}} + +```sql +RESTORE TABLE `test`.`sbtest01`, `test`.`sbtest02` FROM 'local:///mnt/backup/2020/04/'; +``` + +### 远端存储 + +BR 支持从 Amazon S3 或 Google Cloud Storage (GCS) 恢复数据： + +{{< copyable "sql" >}} + +```sql +RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-05/?region=us-west-2'; +``` + +有关详细的 URL 语法，见 [BR 存储](/br/backup-and-restore-storages.md)。 + +当运行在云环境中时，不能分发凭证，可设置 `SEND_CREDENTIALS_TO_TIKV` 选项为 `FALSE`： + +{{< copyable "sql" >}} + +```sql +RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-05/?region=us-west-2' + SEND_CREDENTIALS_TO_TIKV = FALSE; +``` + +### 性能调优 + +如果你需要减少网络带宽占用，可以通过 `RATE_LIMIT` 来限制每个 TiKV 节点的平均下载速度。 + +默认情况下，每个 TiKV 节点上运行 128 个恢复线程。可以通过 `CONCURRENCY` 选项来调整这个值。 + +在恢复完成之前，`RESTORE` 将对备份文件中的数据进行校验，以验证数据的正确性。如果你确信无需进行校验，可以通过 `CHECKSUM` 选项禁用这一步骤。 + +{{< copyable "sql" >}} + +```sql +RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-06/' + RATE_LIMIT = 120 MB/SECOND + CONCURRENCY = 64 + CHECKSUM = FALSE; +``` + +### 增量恢复 + +增量恢复没有特殊的语法。TiDB 将识别备份文件属于全量备份或增量备份，然后执行对应的恢复操作，用户只需按照正确顺序进行增量恢复。 + +假设按照如下方式创建一个备份任务： + +{{< copyable "sql" >}} + +```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; +``` + +在恢复备份时，需要采取同样的顺序： + +{{< copyable "sql" >}} + +```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'; +``` + +## MySQL 兼容性 + +该语句是 TiDB 对 MySQL 语法的扩展。 + +## 另请参阅 + +* [BACKUP](/sql-statements/sql-statement-backup.md) +* [SHOW RESTORES](/sql-statements/sql-statement-show-backups.md) diff --git a/sql-statements/sql-statement-show-backups.md b/sql-statements/sql-statement-show-backups.md new file mode 100644 index 000000000000..764dff7129d3 --- /dev/null +++ b/sql-statements/sql-statement-show-backups.md @@ -0,0 +1,98 @@ +--- +title: SHOW [BACKUPS|RESTORES] +summary: TiDB 数据库中 SHOW [BACKUPS|RESTORES] 的使用概况。 +--- + +# SHOW [BACKUPS|RESTORES] + +`SHOW [BACKUPS|RESTORES]` 语句会列出所有队列中或正在执行的 [`BACKUP`](/sql-statements/sql-statement-backup.md) 和 [`RESTORE`](/sql-statements/sql-statement-restore.md) 任务。 + +查询 `BACKUP` 任务时，使用 `SHOW BACKUPS` 语句。查询 `RESTORE` 任务时，使用 `SHOW RESTORES` 语句。执行两个语句均需要 `SUPER` 权限。 + +## 语法图 + +**ShowBRIEStmt:** + +![ShowBRIEStmt](/media/sqlgram/ShowBRIEStmt.png) + +**ShowLikeOrWhereOpt:** + +![ShowLikeOrWhereOpt](/media/sqlgram/ShowLikeOrWhereOpt.png) + +## 示例 + +在一个连接中，执行以下命令备份数据库： + +{{< copyable "sql" >}} + +```sql +BACKUP DATABASE `test` TO 's3://example-bucket/backup-01/?region=us-west-1'; +``` + +在备份完成之前，在新的连接中执行 `SHOW BACKUPS`： + +{{< copyable "sql" >}} + +```sql +SHOW BACKUPS; +``` + +```sql ++--------------------------------+---------+----------+---------------------+---------------------+-------------+------------+ +| Destination | State | Progress | Queue_Time | Execution_Time | Finish_Time | Connection | ++--------------------------------+---------+----------+---------------------+---------------------+-------------+------------+ +| s3://example-bucket/backup-01/ | Backup | 98.38 | 2020-04-12 23:09:03 | 2020-04-12 23:09:25 | NULL | 4 | ++--------------------------------+---------+----------+---------------------+---------------------+-------------+------------+ +1 row in set (0.00 sec) +``` + +输出结果的第一行描述如下： + +| 列名 | 描述 | +| :-------- | :--------- | +| `Destination` | 目标存储的 URL（为避免泄露密钥，所有参数均不显示） | +| `State` | 任务状态 | +| `Progress` | 当前状态的进度（百分比） | +| `Queue Time` | 任务开始排队的时间 | +| `Execution Time` | 任务开始执行的时间；对于队列中任务，该值为 `0000-00-00 00:00:00` | +| `Finish_Time` | （暂不适用） | +| `Connection` | 运行任务的连接 ID | + +连接 ID 可用于在 [`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md) 语句中取消备份/恢复任务： + +{{< copyable "sql" >}} + +```sql +KILL TIDB QUERY 4; +``` + +```sql +Query OK, 0 rows affected (0.00 sec) +``` + +### 过滤 + +在 `LIKE` 子句中使用通配符，可以按目标存储 URL 筛选任务： + +{{< copyable "sql" >}} + +```sql +SHOW BACKUPS LIKE 's3://%'; +``` + +使用 `WHERE` 子句，可以按列筛选任务： + +{{< copyable "sql" >}} + +```sql +SHOW BACKUPS WHERE `Progress` < 25.0; +``` + +## MySQL 兼容性 + +该语句是 TiDB 对 MySQL 语法的扩展。 + +## 另请参阅 + +* [BACKUP](/sql-statements/sql-statement-backup.md) +* [RESTORE](/sql-statements/sql-statement-restore.md)