小编点评

## Backup 语句引擎与 BR 工具的比较 **引擎：** TiDB 本身驱动，而非单独的 BR 工具。 **优势：** * 使用 BR 工具可能会导致阻塞，因为需要等待所有 TiKV 节点执行备份操作。 * 由于使用 TiDB 本身驱动，备份过程更加快速。 **警告：** * 由于使用 BR 工具可能会阻塞，所以备份过程只能执行一个。 * 执行备份需要准备一个持久的连接。 * 备份过程中，外部存储 BR 支持备份数据到 Amazon S3 或 Google Cloud Storage (GCS)。 **语法：** ```sql BACKUP [DATABASE_NAME] TO 'destination_path' [OPTIONS]; ``` **示例：** ```sql BACKUP DATABASE `test` TO 'local:///mnt/backup/2020/04/'; ``` **其他选项：** * `RATE_LIMIT`：限制每个 TiKV 节点的平均上传速度。 * `CHECKSUM`：禁用数据校验。 * `LAST_BACKUP`：只备份从上一次备份到当前快照之间的增量数据。 * `SNAPSHOT`：指定快照时间戳。 **注意：** * 对于相对时间，支持以下时间单位：微秒、秒、分钟、小时、天、周。

正文

https://docs.pingcap.com/zh/tidb/v4.0/sql-statement-restore

BACKUP 语句使用的引擎与 BR 相同，但备份过程是由 TiDB 本身驱动，而非单独的 BR 工具。BR 工具的优势和警告也适用于 BACKUP 语句。

执行 BACKUP 需要 SUPER 权限。此外，执行备份的 TiDB 节点和集群中的所有 TiKV 节点都必须有对目标存储的读或写权限。

BACKUP 语句开始执行后将会被阻塞，直到整个备份任务完成、失败或取消。因此，执行 BACKUP 时需要准备一个持久的连接。如需取消任务，可执行 KILL TIDB QUERY 语句。

一次只能执行一个 BACKUP 和 RESTORE 任务。如果 TiDB server 上已经在执行一个 BACKUP 或 RESTORE 语句，新的 BACKUP 将等待前面所有的任务完成后再执行。

语法图

示例

备份数据库

上述示例中，test 数据库被备份到本地，数据以 SST 文件的形式存储在分布于所有 TiDB 和 TiKV 节点的 /mnt/backup/2020/04/ 目录中。

输出结果的第一行描述如下：

列名	描述
Destination	目标存储的 URL
Size	备份文件的总大小，单位为字节
BackupTS	创建备份时的快照 TSO（用于增量备份）
Queue Time	BACKUP 任务开始排队的时间戳（当前时区）
Execution Time	BACKUP 任务开始执行的时间戳（当前时区）

备份表

备份集群

注意，备份中不包含系统表 (mysql.*、INFORMATION_SCHEMA.*、PERFORMANCE_SCHEMA.* 等)。

外部存储

BR 支持备份数据到 Amazon S3 或 Google Cloud Storage (GCS)：

有关详细的 URL 语法，见外部存储。

当运行在云环境中时，不能分发凭证，可设置 SEND_CREDENTIALS_TO_TIKV 选项为 FALSE：

性能调优

如果你需要减少网络带宽占用，可以通过 RATE_LIMIT 来限制每个 TiKV 节点的平均上传速度。

默认情况下，每个 TiKV 节点上运行 4 个备份线程。可以通过 CONCURRENCY 选项来调整这个值。

在备份完成之前，BACKUP 将对集群上的数据进行校验，以验证数据的正确性。如果你确信无需进行校验，可以通过 CHECKSUM 选项禁用这一步骤。

快照

可以指定一个时间戳、TSO 或相对时间，来备份历史数据。

对于相对时间，支持以下时间单位：

• MICROSECOND（微秒）
• SECOND（秒）
• MINUTE（分钟）
• HOUR（小时）
• DAY（天）
• WEEK（周）

注意，相对时间的单位遵循 SQL 标准，永远使用单数。

增量备份

提供 LAST_BACKUP 选项，只备份从上一次备份到当前快照之间的增量数据。

MySQL 兼容性

该语句是 TiDB 对 MySQL 语法的扩展。

另请参阅

• RESTORE
• SHOW BACKUPS