[转帖]tidb RESTORE

tidb,restore · 浏览次数 : 0

小编点评

## Restore RESTORE 语句说明 **简介:** `RESTORE` 语句用于执行分布式恢复,将 `BACKUP` 生成的备份文件恢复到 TiDB 集群中。 **语法:** ```sql RESTORE FROM 'path/to/backup_file' [] ``` **参数:** * `database_name`: 目标数据库名称。 * `path/to/backup_file`: 备份文件的路径。 * `options`: 可选参数,控制恢复过程。 **可选参数:** * `RATE_LIMIT`: 控制每个 TiKV 节点的平均下载速度。 * `CHECKSUM`: 是否对备份文件中的数据进行校验。 * `CONCURRENCY`: 设置每个 TiKV 节点的恢复线程数量。 **注意:** * `RESTORE` 语句目前不遵循 ACID 原则。 * 执行全量恢复时,请确保即将恢复的表不存在于集群中。 * 增量恢复需要按照正确的顺序执行。 * 只能在 ``tikv`` 存储引擎上使用 `RESTORE` 语句。 **示例:** ```sql RESTORE DATABASE `test` FROM 'local:///mnt/backup/2020/04/'; ``` 这将从本地目录中恢复所有数据并将其写入 `test` 数据库中。 **性能调优:** * 通过设置 `RATE_LIMIT` 来限制网络带宽占用。 * 通过设置 `CONCURRENCY` 来调整恢复线程数量。

正文

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

RESTORE 语句用于执行分布式恢复,把 BACKUP 语句生成的备份文件恢复到 TiDB 集群中。

RESTORE 语句使用的引擎与 BR 相同,但恢复过程是由 TiDB 本身驱动,而非单独的 BR 工具。BR 工具的优势和警告也适用于 RESTORE 语句。需要注意的是,RESTORE 语句目前不遵循 ACID 原则。

执行 RESTORE 语句前,确保集群已满足以下要求:

  • 集群处于“下线”状态,当前的 TiDB 会话是唯一在访问待恢复表的活跃 SQL 连接。
  • 执行全量恢复时,确保即将恢复的表不存在于集群中,因为现有的数据可能被覆盖,从而导致数据与索引不一致。
  • 执行增量恢复时,表的状态应该与创建备份时 LAST_BACKUP 时间戳的状态完全一致。

执行 RESTORE 需要 SUPER 权限。此外,执行恢复操作的 TiDB 节点和集群中的所有 TiKV 节点都必须有对目标存储的读权限。

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

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

RESTORE 只能在 "tikv" 存储引擎上使用,如果使用 "mocktikv" 存储引擎,RESTORE 操作会失败。

语法图

RestoreStmt
RESTOREBRIETablesFROMstringLitRestoreOption
BRIETables
DATABASE*DBName,TABLETableNameList
RestoreOption
RATE_LIMIT=LengthNumMB/SECONDCONCURRENCY=LengthNumCHECKSUM=BooleanSEND_CREDENTIALS_TO_TIKV=Boolean
Boolean
NUMTRUEFALSE

示例

从备份文件恢复

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)

上述示例中,所有数据均从本地的备份文件中恢复到集群中。RESTORE 从 SST 文件里读取数据,SST 文件存储在所有 TiDB 和 TiKV 节点的 /mnt/backup/2020/04/ 目录下。

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

列名描述
Destination 读取的目标存储 URL
Size 备份文件的总大小,单位为字节
BackupTS 不适用
Queue Time RESTORE 任务开始排队的时间戳(当前时区)
Execution Time RESTORE 任务开始执行的时间戳(当前时区)

部分恢复

你可以指定恢复部分数据库或部分表数据。如果备份文件中缺失了某些数据库或表,缺失的部分将被忽略。此时,RESTORE 语句不进行任何操作即完成执行。

RESTORE DATABASE `test` FROM 'local:///mnt/backup/2020/04/';
RESTORE TABLE `test`.`sbtest01`, `test`.`sbtest02` FROM 'local:///mnt/backup/2020/04/';

外部存储

BR 支持从 Amazon S3 或 Google Cloud Storage (GCS) 恢复数据:

RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-05/?region=us-west-2';

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

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

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 选项禁用这一步骤。

RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-06/' RATE_LIMIT = 120 MB/SECOND CONCURRENCY = 64 CHECKSUM = FALSE;

增量恢复

增量恢复没有特殊的语法。TiDB 将识别备份文件属于全量备份或增量备份,然后执行对应的恢复操作,用户只需按照正确顺序进行增量恢复。

假设按照如下方式创建一个备份任务:

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;

在恢复备份时,需要采取同样的顺序:

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 语法的扩展。

另请参阅

与[转帖]tidb RESTORE相似的内容:

[转帖]tidb RESTORE

https://docs.pingcap.com/zh/tidb/v4.0/sql-statement-restore RESTORE 语句用于执行分布式恢复,把 BACKUP 语句生成的备份文件恢复到 TiDB 集群中。 RESTORE 语句使用的引擎与 BR 相同,但恢复过程是由 TiDB 本身

[转帖]TIDB - 使用BR工具进行数据热备份与恢复

一、BR工具 BR 全称为 Backup & Restore,是 TiDB 分布式备份恢复的命令行工具,用于对 TiDB 集群进行数据备份和恢复。BR 只支持在 TiDB v3.1 及以上版本使用。 在前面的章节中,我们介绍了dumpling将数据导出的方式,也可以作为一种备份的方式,并且导出的数据

[转帖]TIDB - 使用BR工具进行数据热备份与恢复

一、BR工具 BR 全称为 Backup & Restore,是 TiDB 分布式备份恢复的命令行工具,用于对 TiDB 集群进行数据备份和恢复。BR 只支持在 TiDB v3.1 及以上版本使用。 在前面的章节中,我们介绍了dumpling将数据导出的方式,也可以作为一种备份的方式,并且导出的数据

[转帖]tidb backup

https://docs.pingcap.com/zh/tidb/v4.0/sql-statement-restore BACKUP 语句使用的引擎与 BR 相同,但备份过程是由 TiDB 本身驱动,而非单独的 BR 工具。BR 工具的优势和警告也适用于 BACKUP 语句。 执行 BACKUP 需

[转帖]备份与恢复工具 BR 简介

https://docs.pingcap.com/zh/tidb/v4.0/backup-and-restore-tool BR 全称为 Backup & Restore,是 TiDB 分布式备份恢复的命令行工具,用于对 TiDB 集群进行数据备份和恢复。BR 只支持在 TiDB v3.1 及以上版

[转帖]使用 Dumpling 和 TiDB Lightning 备份与恢复

https://docs.pingcap.com/zh/tidb/stable/backup-and-restore-using-dumpling-lightning 本文档介绍如何使用 Dumpling 和 TiDB Lightning 进行全量备份与恢复。 在备份与恢复场景中,如果需要全量备份少

[转帖]TiDB 适配应用实践:MyBatis 3.5.X 在 JDK8 中性能问题的排查与优化

https://zhuanlan.zhihu.com/p/371638037 作者介绍:PingCAP Tech Center,于旸。 最近有金融客户使用 TiDB 适配批处理场景,数据量在数亿级。对于相同数据量的处理耗时,TiDB 要 35 分钟,而某商业数据库只要 15 分钟,足足相差 20 分

[转帖]tidb集群部署

http://blog.itpub.net/29785807/viewspace-2789852/ 一.安装规划 1 2 3 4 5 6 使用15台服务器 5台tidb服务器:每台3个tidb实例+1个pd+1个pump 10台tikv服务器:每台4个tikv实例 drainer_servers 安

[转帖]tidb 修改root密码

http://blog.51yip.com/tidb/2452.html 通过 {pd-ip}:{pd-port}/dashboard 登录 TiDB Dashboard,登录用户和口令为 TiDB 数据库 root 用户和口令。如果你修改过数据库的 root 密码,则以修改后的密码为准,默认密码为

[转帖]tidb 搭建私有镜像库

https://docs.pingcap.com/zh/tidb/stable/tiup-mirror 在构建私有云时,通常会使用隔离的网络环境,此时无法访问 TiUP 的官方镜像。因此,TiUP 提供了构建私有镜像的方案,它主要由 mirror 指令来实现,该方案也可用于离线部署。使用私有镜像,你