戻す

このステートメントは、以前にBACKUPステートメントによって作成されたバックアップアーカイブから分散復元を実行します。

RESTOREステートメントはBRツールと同じエンジンを使用しますが、復元プロセスが個別のBRツールではなくTiDB自体によって駆動される点が異なります。 BRのすべての利点と警告もここに適用されます。特に、 RESTOREは現在ACIDに準拠していません。 RESTOREを実行する前に、次の要件が満たされていることを確認してください。

• クラスタは「オフライン」であり、現在のTiDBセッションは、復元されるすべてのテーブルにアクセスするための唯一のアクティブなSQL接続です。
• 完全な復元が実行されている場合、既存のデータが上書きされ、データとインデックスの間に不整合が生じる可能性があるため、復元されるテーブルはまだ存在していないはずです。
• インクリメンタルリストアが実行されている場合、テーブルはバックアップが作成されたときのLAST_BACKUPタイムスタンプとまったく同じ状態である必要があります。

RESTOREを実行するには、 RESTORE_ADMINまたはSUPERの特権が必要です。さらに、復元を実行するTiDBノードとクラスタのすべてのTiKVノードの両方に、宛先からの読み取り権限が必要です。

RESTOREステートメントはブロックされており、復元タスク全体が終了、失敗、またはキャンセルされた後にのみ終了します。 RESTOREを実行するには、長期的な接続を準備する必要があります。タスクは、 KILL TIDB QUERYステートメントを使用してキャンセルできます。

一度に実行できるタスクはBACKUPつとRESTOREつだけです。 BACKUPまたはRESTOREのタスクが同じTiDBサーバーですでに実行されている場合、新しいRESTOREの実行は、前のすべてのタスクが完了するまで待機します。

RESTOREは、「tikv」ストレージエンジンでのみ使用できます。 「unistore」エンジンでRESTOREを使用すると失敗します。

あらすじ

RestoreStmt ::=
    "RESTORE" BRIETables "FROM" stringLit RestoreOption*

BRIETables ::=
    "DATABASE" ( '*' | DBName (',' DBName)* )
|   "TABLE" TableNameList

RestoreOption ::=
    "RATE_LIMIT" '='? LengthNum "MB" '/' "SECOND"
|   "CONCURRENCY" '='? LengthNum
|   "CHECKSUM" '='? Boolean
|   "SEND_CREDENTIALS_TO_TIKV" '='? Boolean

Boolean ::=
    NUM | "TRUE" | "FALSE"

例

バックアップアーカイブから復元

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)

上記の例では、すべてのデータがローカルファイルシステムのバックアップアーカイブから復元されます。データは、すべてのTiDBノードとTiKVノードに分散された/mnt/backup/2020/04/のディレクトリからSSTファイルとして読み取られます。

上記の結果の最初の行は次のように説明されています。

部分的な復元

復元するデータベースまたはテーブルを指定できます。一部のデータベースまたはテーブルがバックアップアーカイブから欠落している場合、それらは無視されるため、 RESTOREは何もせずに完了します。

RESTORE DATABASE `test` FROM 'local:///mnt/backup/2020/04/';

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

外部ストレージ

BRは、S3または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ノードあたりの平均ダウンロード速度を制限し、ネットワーク帯域幅を減らします。

デフォルトでは、TiDBノードは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の互換性

このステートメントは、MySQL構文のTiDB拡張です。

も参照してください

• バックアップ
• 復元を表示