復元する

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

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

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

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

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

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

RESTORE 「tikv」storageエンジンでのみ使用できます。 「unistore」エンジンで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)

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

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

カラム説明
Destination読み取り先の URL
Sizeバックアップ アーカイブの合計サイズ (バイト単位)
BackupTS(使用されていない)
Queue TimeRESTOREのタスクがキューに入れられたときのタイムスタンプ (現在のタイムゾーン)。
Execution TimeRESTOREタスクの実行が開始されたときのタイムスタンプ (現在のタイムゾーン)。

部分復元

どのデータベースまたはテーブルを復元するかを指定できます。一部のデータベースまたはテーブルがバックアップ アーカイブにない場合、それらは無視されるため、 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/';

URL 構文については、 外部ストレージ サービスの URI 形式で詳しく説明します。

URL 構文については、 外部storageURIで詳しく説明します。

認証情報を配布しないクラウド環境で実行する場合は、 SEND_CREDENTIALS_TO_TIKVオプションをFALSEに設定します。

RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-05/' 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 拡張機能です。

こちらも参照

このページは役に立ちましたか?

Playground
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.