リストア
説明
このステートメントは、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を指定することで、復元中にこれらの余分なテーブルを削除してリサイクルビンに移動できます。- この機能はApache Doris 2.1.6バージョン以降でサポートされています
- "clean_partitions": 復元ターゲットに属さないパーティションをクリーンアップするかどうかを示します。例えば、復元前のターゲットテーブルにスナップショットに存在しないパーティションがある場合、
clean_partitionsを指定することで、復元中にこれらの余分なパーティションを削除してリサイクルビンに移動できます。- この機能は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コマンドを実行するユーザーは、少なくとも以下の権限を持つ必要があります:
| 権限 | オブジェクト | 注記 |
|---|---|---|
| LOAD_PRIV | USER or ROLE | この操作はLOAD_PRIV権限を持つユーザーまたはロールのみが実行できます |
使用上の注意
- OLAP型のテーブルの復元のみがサポートされています。
- 同じデータベース下で実行中のBACKUPまたはRESTOREタスクは1つだけ存在できます。
- ウェアハウスでバックアップされたテーブルを復元して、データベース内の同名の既存テーブルを置き換えることができますが、2つのテーブルの構造が完全に同じであることを確認する必要があります。テーブル構造には、テーブル名、列、パーティション、Rollupなどが含まれます。
- 復旧テーブルの一部のパーティションを指定でき、システムはパーティションのRangeまたはListがマッチするかどうかをチェックします。
- ウェアハウスでバックアップされたテーブル名は、AS文を通じて新しいテーブルに復元できます。ただし、新しいテーブル名はデータベースに既に存在していてはいけません。パーティション名は変更できません。
- 復旧操作の効率:同じクラスターサイズの場合、復元操作の所要時間は基本的にバックアップ操作の所要時間と同じです。復旧操作を高速化したい場合は、
replication_numパラメータを設定して最初に1つのコピーのみを復元し、その後ALTER TABLE PROPERTYでコピー数を調整して、コピーを完成させることができます。
例
- example_repoから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"
);
- example_repoのバックアップsnapshot_2内のテーブルbackup_tblのパーティションp1、p2、およびテーブルbackup_tbl2をデータベース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からdatabase example_db1に、backup snapshot_3内のtable backup_tblを除く全てのテーブルを復元します。時刻バージョンは"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"
);