RESTORE
説明
このステートメントは、BACKUPコマンドでバックアップされたデータを指定されたデータベースに復元するために使用されます。このコマンドは非同期操作です。送信が成功した後、SHOW RESTOREコマンドを通じて進行状況を確認する必要があります。
構文
RESTORE SNAPSHOT [<db_name>.]<snapshot_name>
FROM `<repository_name>`
[ { ON | EXCLUDE } ] (
`<table_name>` [PARTITION (`<partition_name>`, ...)] [AS `<table_alias>`]
[, ...] ) ]
)
[ PROPERTIES ( "<key>" = "<value>" [ , ... ] )]
必須パラメータ
1.<db_name>
復元するデータが属するデータベースの名前
2.<snapshot_name>
データスナップショット名
3.<repository_name>
ウェアハウス名。CREATE REPOSITORYでリポジトリを作成できます
4.[ PROPERTIES ( "<key>" = "<value>" [ , ... ] ) ]
復元操作の属性、形式は<key> = <value>、現在以下のプロパティをサポートしています:
- "backup_timestamp" = "2018-05-04-16-45-08": 復元する対応するバックアップのタイムバージョンを指定、必須。この情報は
SHOW SNAPSHOT ON repo;文で取得できます。 - "replication_num" = "3": 復元するテーブルまたはパーティションのレプリカ数を指定。デフォルトは3。既存のテーブルまたはパーティションを復元する場合、レプリカ数は既存のテーブルまたはパーティションのレプリカ数と同じである必要があります。同時に、複数のレプリカを収容するのに十分なホストが必要です。
- "reserve_replica" = "true": デフォルトはfalse。このプロパティがtrueの場合、replication_numプロパティは無視され、復元されるテーブルまたはパーティションはバックアップ前と同じレプリケーション数を持ちます。テーブル内の複数のテーブルまたは複数のパーティションで異なるレプリケーション数をサポートします。
- "reserve_dynamic_partition_enable" = "true": デフォルトはfalse。このプロパティがtrueの場合、復元されるテーブルはバックアップ前と同じ'dynamic_partition_enable'値を持ちます。このプロパティがtrueでない場合、復元されるテーブルは'dynamic_partition_enable=false'を設定します。
- "timeout" = "3600": タスクのタイムアウト期間、デフォルトは1日。秒単位。
- "meta_version" = 40: 指定されたmeta_versionを使用して以前にバックアップされたメタデータを読み取ります。このパラメータは一時的な解決策として使用され、Dorisの古いバージョンでバックアップされたデータを復元するためだけに使用されることに注意してください。最新バージョンのバックアップデータには既にmetaバージョンが含まれているため、指定する必要はありません。
- "clean_tables": 復元ターゲットに属さないテーブルをクリーンアップするかどうかを示します。例えば、復元前のターゲットdbにスナップショットに存在しないテーブルがある場合、
clean_tablesを指定することで復元中にこれらの余分なテーブルを削除してrecycle binに移動できます。- この機能はApache Doris 2.1.6バージョン以降でサポートされています
- "clean_partitions": 復元ターゲットに属さないパーティションをクリーンアップするかどうかを示します。例えば、復元前のターゲットテーブルにスナップショットに存在しないパーティションがある場合、
clean_partitionsを指定することで復元中にこれらの余分なパーティションを削除してrecycle binに移動できます。- この機能はApache Doris 2.1.6バージョン以降でサポートされています
- "atomic_restore": データは最初に一時テーブルにロードされ、その後元のテーブルがアトミックに置換されて、復旧プロセス中にターゲットテーブルの読み書きが影響を受けないことを保証します。
- "force_replace": テーブルが存在し、スキーマがバックアップテーブルと異なる場合に強制置換します。
- "force_replace"を有効にするには、"atomic_restore"を有効にする必要があることに注意してください
オプションパラメータ
1.<table_name>
復元するテーブルの名前。指定されていない場合、データベース全体が復元されます。
- 復元が必要なテーブルとパーティションはON句で識別されます。パーティションが指定されていない場合、デフォルトでテーブルのすべてのパーティションが復元されます。指定されたテーブルとパーティションは既にウェアハウスバックアップに存在している必要があります。
- 復旧が不要なテーブルとパーティションはEXCLUDE句で識別されます。指定されたテーブルまたはパーティションを除くウェアハウス内の他のすべてのテーブルのすべてのパーティションが復元されます。
2.<partition_name>
復元するパーティションの名前。指定されていない場合、対応するテーブルのすべてのパーティションが復元されます。
3.<table_alias>
テーブルエイリアス
アクセス制御要件
このSQLコマンドを実行するユーザーは、少なくとも以下の権限を持っている必要があります:
| Privilege | Object | Notes |
|---|---|---|
| LOAD_PRIV | USER or ROLE | この操作はLOAD_PRIV権限を持つユーザーまたはロールのみが実行できます |
使用上の注意
- OLAP型のテーブルの復元のみサポートされています。
- 同じデータベース下で実行できるBACKUPまたはRESTOREタスクは1つだけです。
- ウェアハウス内でバックアップされたテーブルを復元して、データベース内の同名の既存テーブルを置換できますが、2つのテーブルの構造が完全に同じであることを確認する必要があります。テーブル構造には、テーブル名、カラム、パーティション、Rollupなどが含まれます。
- 復旧テーブルの一部のパーティションを指定でき、システムはパーティションRangeまたはListがマッチできるかどうかをチェックします。
- ウェアハウスでバックアップされたテーブル名は、AS文を通じて新しいテーブルに復元できます。ただし、新しいテーブル名はデータベースに既に存在してはいけません。パーティション名は変更できません。
- 復旧操作の効率:同じクラスターサイズの場合、復元操作の所要時間は基本的にバックアップ操作の所要時間と同じです。復旧操作を高速化したい場合は、
replication_numパラメータを設定して最初に1つのコピーのみを復元し、その後ALTER TABLE PROPERTYでコピー数を調整して、コピーを完成させることができます。
例
- example_repoからbackup snapshot_1内のテーブルbackup_tblをデータベースexample_db1に復元、タイムバージョンは"2018-05-04-16-45-08"。1つのコピーに復元:
RESTORE SNAPSHOT example_db1.`snapshot_1`
FROM `example_repo`
ON ( `backup_tbl` )
PROPERTIES
(
"backup_timestamp"="2018-05-04-16-45-08",
"replication_num" = "1"
);
- backup snapshot_2 内の example_repo から table backup_tbl のパーティション p1, p2 を復元し、table backup_tbl2 を database example_db1 に復元して new_tbl にリネームします。時刻バージョンは "2018-05-04-17-11-01" です。デフォルトで 3 レプリカに戻されます:
RESTORE SNAPSHOT example_db1.`snapshot_2`
FROM `example_repo`
ON
(
`backup_tbl` PARTITION (`p1`, `p2`),
`backup_tbl2` AS `new_tbl`
)
PROPERTIES
(
"backup_timestamp"="2018-05-04-17-11-01"
);
- example_repo から snapshot_3 のバックアップにある backup_tbl 以外のすべてのテーブルを、データベース example_db1 に復元します。時刻バージョンは "2018-05-04-18-12-18" です。
RESTORE SNAPSHOT example_db1.`snapshot_3`
FROM `example_repo`
EXCLUDE ( `backup_tbl` )
PROPERTIES
(
"backup_timestamp"="2018-05-04-18-12-18"
);