テーブル単位のリストア

この記事では、テーブル単位のリストア方法について説明します。

テーブル単位のリストア

テーブル単位のリストアにおける「補助テナントの物理リストア」フェーズには、完全リストアと高速リストアの2つの方式があります。

テーブル単位のリストアプロセス には、補助テナントの物理リストア、テナント間のテーブルインポート、補助テナントのクリーンアップという3つのフェーズがあります。以前のバージョンでは、補助テナントの物理リストアフェーズで完全リストア方式が採用されていました。この方式では、ソーステナントの全データをバックアップメディアから補助テナントにリストアする必要があり、以下の2つの問題がありました。

1. 一時的な補助テナントのリストアに対応するため、ユーザーはクラスタ上に十分なCPU、メモリ、ディスクリソースを確保する必要があります。
2. 全データをバックアップメディアから補助テナントにリストアするプロセスにおいて、大量の時間とネットワーク帯域幅を消費します。

これらの問題を解決するため、OceanBaseデータベース V4.3.5 BP1バージョンより、高速リストア方式による補助テナントのリストアがサポートされました。この方式で補助テナントをリストアする場合、読み取り専用の補助テナントのみをリストアすればよく、テナント内のユーザーデータをバックアップメディアから完全にリストアする必要はありません。テナント間のテーブルインポートフェーズにおいて、リストア対象テーブルのバックアップマクロブロックデータをバックアップメディアから直接読み取るだけで済みます。この方式により、テーブル単位のリストアにおける一時的な補助テナントのリソース使用量を削減でき、かつリストアタスクの所要時間を短縮できます。

テーブル単位のリストアを実行した後、sys テナントでビュー CDB_OB_RESTORE_HISTORY の RESTORE_TYPE 列をクエリすることで、支援テナントのリストア方式を確認できます。

制限事項と注意事項

• ユーザーテーブルのリストアのみをサポートし、一時テーブル、ビュー、マテリアライズドビュー、マテリアライズドビュー・ログ、インデックスなどの個別リストアはサポートされません。

• V4.3.5バージョンでは、V4.3.5 BP2バージョンから、列指向ストレージと行列混在ストレージ形式のテーブルのリストアをサポートします。

• V4.3.5バージョンでは：

  • V4.3.5 BP3および以前のバージョンでは、全文インデックス、JSON多値インデックス、またはベクトルインデックスを持つテーブルのリストアはサポートされません。
  • V4.3.5 BP4バージョン以降では、全文インデックス、JSON多値インデックス、またはベクトルインデックスを持つテーブルのリストアをサポートします。

• テーブルのリストアでは、ソーステナントとターゲットテナントの互換性が一致している必要があります。例えば、どちらもOracle互換性テナントであるか、どちらもMySQL互換性テナントである必要があります。

• テーブルのリストアでは、指定するテーブル名はシステムが実際に格納しているテーブル名と一致している必要があります。例えば、Oracleモードのテナントでテーブル test を作成した場合、システム内部で実際に格納されているテーブル名が TEST であるため、テーブルをリストアする際にはテーブル名を TEST と指定する必要があります。そうでない場合、システムはエラーを返して、テーブルが存在しないと通知します。

• テナント単位のリストアでサポートされているバックアップデータのバージョンと同様に、テーブル単位のリストアでは、現在は低バージョンのバックアップデータから、同じバージョンまたは高バージョンのテーブルへのリストアのみをサポートしています。同じバージョンの小バージョン間での逆リストアもサポートされていません。テナント単位のリストアでサポートされているバックアップデータのバージョンの詳細については、リストア前の準備を参照してください。

• テーブル単位のリストアでは、テーブルのリストアに加えて、そのテーブルに関連する多くの情報もリストアされます。ただし、一部の情報はリストアされません。リストア可能な情報の詳細については、テーブル単位のリストアのスキーマリストアの説明を参照してください。

前提条件

指定されたテーブルのリストアプロセスでは、サブテナントを使用する必要があるため、テーブルリストアを行う前に、ターゲットテナントが存在するクラスタ内でサブテナント用のリソースプールを作成する必要があります。サブテナント用のリソースプールの作成手順については、テーブルレベルのリストア前の準備を参照してください。

手順

1. root ユーザーを使用して、ターゲットテナントが存在するクラスタの sys テナントにログインします。

2. （オプション）リストア対象のテーブルで使用するバックアップデータに暗号化機能が設定されている場合は、バックアップセットの暗号化情報を設定する必要があります。

   データのバックアップ時にのみパスワードが追加された場合に、バックアップのリストアパスワードを設定する必要があります。

   SET DECRYPTION IDENTIFIED BY 'password';
   

   ここで、password はバックアップ時に追加されたパスワードに置き換える必要があります。フルバックアップとインクリメンタルバックアップで設定されたパスワードが異なる場合、複数のパスワードを入力する必要があります。パスワードは英数字のカンマで区切ります（フルバックアップのパスワードを前に、インクリメンタルバックアップのパスワードを後に配置します）。

   フルバックアップとインクリメンタルバックアップで設定されたパスワードが同じ場合の例は次のとおりです：

   SET DECRYPTION IDENTIFIED BY '******';
   

   フルバックアップとインクリメンタルバックアップで設定されたパスワードが異なる場合の例は次のとおりです：

   SET DECRYPTION IDENTIFIED BY '******','******';
   

3. （オプション）テーブル単位のリストア並列度を設定します。

   • 単一テーブルの並列リストア

     テーブル単位のリストアを実行する前に、構成パラメータ recover_table_dop を使用して並列度を設定できます。設定後、システムは次の2つのフェーズでこの並列度を使用します：

     • メインテーブルデータリストアフェーズ：システムはメインテーブルの各パーティションを複数のサブタスクに分割して並行して実行します。
     • インデックスリストアフェーズ：システムはリストアされたメインテーブルデータに基づいて、並行実行（Parallel Execution, PX）を使用してテーブルのインデックスを再構築します。

     構文は次のとおりです：

     -- tenant_name はターゲットテナント
     ALTER SYSTEM SET recover_table_dop=INT_VALUE tenant=tenant_name;
     

   • 複数テーブルの並列リストア（オプション）

     テーブル単位の複数テーブルリストアを実行する前に、構成パラメータ recover_table_concurrency を使用して並列度を設定できます。設定後、複数のテーブルが並行してリストアタスクを実行できるため、リストアパフォーマンスが向上します。

     構文は次のとおりです：

     -- tenant_name はターゲットテナント
     ALTER SYSTEM SET recover_table_concurrency=INT_VALUE tenant=tenant_name;
     

   • テナントの各observerノード上のメインテーブルデータリストアワーカースレッド数の設定

     単一テーブル並列度 recover_table_dop と複数テーブル並列度 recover_table_concurrency を設定した後、ddl_thread_score 構成パラメータを使用して、テナントの各observerノード上の補データワーカースレッド数を設定する必要があります。テーブル単位のリストアでは、テナント間のテーブル移行フェーズでメインテーブルデータリストアは、ターゲットテナント上の特定のDAGスレッドに依存します。

     構文は次のとおりです：

     -- tenant_name はターゲットテナント
     ALTER SYSTEM SET ddl_thread_score=INT_VALUE tenant=tenant_name;
     

     注意

     • 物理リストアのアシスタントテナント実行フェーズでは、ha_high_thread_score設定項目を調整することで、リストアの並列度を動的に調整できます。調整は即時に反映されます。この中で、アシスタントテナント名は、テーブル単位のリストアタスクの進捗状況テーブルCDB_OB_RECOVER_TABLE_JOBSで確認できます。具体的な調整については、物理リストアを参照してください。
     • テナント間のテーブル導出フェーズでは、ターゲットテナントのrecover_table_concurrencyまたはrecover_table_dop設定項目を調整することで、複数テーブル/単一テーブルのリストアの並列度を動的に調整できます。調整は即時に反映されます。

4. 指定されたテーブルをリストアするには、次のコマンドを実行します。

   SQLステートメントは次のとおりです：

   ALTER SYSTEM 
   RECOVER TABLE table_name_list 
   TO [TENANT [=]] dest_tenant_name 
   FROM uri 
   [UNTIL {TIME='timestamp'} | {SCN=scn} ]
   WITH 'restore_option' 
   [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password']
   [REMAP TABLE remap_table_name_list] 
   [REMAP TABLEGROUP remap_tablegroup_list] 
   [REMAP TABLESPACE remap_tablespace_list]
   [DESCRIPTION [=] description];
   

   関連パラメータの説明は次のとおりです：

   • table_name_list：リストアするテーブル。形式はdatabase_name.table_name1,database_name.table_name2,...で、複数のテーブルは英数字のカンマ（,）で区切ります。

     database_nameとtable_nameを指定する場合：

     • table_nameはシステムが実際に格納するテーブル名と一致する必要があります。例えば、Oracleモードのテナントでテーブルtestを作成すると、システム内部で実際に格納されるテーブル名はTESTになります。そのため、テーブルをリストアする際にはテーブル名をTESTと指定する必要があります。そうでない場合、システムはテーブルが存在しないというエラーを返します。

     • database_nameまたはtable_nameに特殊文字が含まれる場合、特殊文字を含むdatabase_nameまたはtable_nameはバッククォート（``）で囲む必要があります。

     • データベース内のすべてのテーブルをリストアする必要がある場合は、database_name.*と指定できます。

     • テナント内のすべてのユーザーテーブルをリストアする必要がある場合は、*.*と指定できます。

   • dest_tenant_name：テーブルをリストアする対象のテナント名。テーブルをユーザーテナントにのみリストアできます。sysテナントまたはMetaテナントにはリストアできません。

   • uri：データバックアップとログアーカイブのパスをそれぞれ指定します。テナント単位の物理リストアコマンドと同じパラメータを使用します。データバックアップがPLUS ARCHIVELOG方式で開始されている場合は、パスを1つだけ指定すればよいですが、そうでない場合はデータバックアップとログアーカイブのパスを少なくとも2つ入力する必要があります。例：'file:///backup/archive, file:///backup/data'。

   • {TIME='timestamp'} \| {SCN=scn}：指定されたリストア終了点。このポイントまでリストアし、このポイントを含める必要があります。TIMEまたはSCNを指定する場合、指定値に=を接続する必要があります。UNTIL句を指定しない場合、デフォルトでは最新のポイントまでリストアされます。

   • restore_option：アシスタントテナントのpool_list、locality、primary_zone、concurrencyを指定します。異なるパラメータは&で区切ります。localityとprimary_zoneを指定する場合、ソーステナントと同様の構造を維持することを推奨します。

     concurrencyを指定しない場合、デフォルトではそのアシスタントテナントに割り当てられたMAX_CPU数と同じ値になります。例えば、本記事では、システムテナントがアシスタントテナントにMAX_CPU=16を割り当てています。

     各パラメータの詳細については、テーブル単位のリストア関連パラメータの紹介を参照してください。

   • WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'：暗号化されたテナントのキーのバックアップ情報を指定します。ソーステナントで透過的暗号化が設定されている場合にのみ、リストア時にキーのバックアップ情報を指定する必要があります。

     • backup_key_path：キーのバックアップパスです。

     • password：キーのバックアップ時に設定した暗号化パスワードです。

     秘密鍵のバックアップに関する操作については、バックアップ前の準備のキーのバックアップを参照してください。

   • remap_table_name_list：リストア後のテーブル名をリネームします。テーブル名のみをリネームし、テーブルが属するデータベースは変更しないことも可能です。また、テーブル名を変更せず、テーブルを他のデータベースにリネームすることも可能です。さらに、テーブル名とテーブルが属するデータベースの両方をリネームすることも可能です。ソースオブジェクトとリネームオブジェクトは、英数字のコロン（:）で接続します。具体的な形式の例は以下のとおりです：

     • テーブル名を student から student2 にリネームし、テーブルが属するデータベースは変更しない：REMAP TABLE school.student:student2。

       テーブルが属するデータベースが変更されない場合、リストア先のテナントでテーブルを作成する際、システムはデフォルトでテーブルをリストア先のテナントの同名のデータベースにリストアします。同名のデータベースが存在しない場合、テーブルのリストアは失敗します。

     • テーブル名を変更せず、テーブルが属するデータベースを school から college に変更：REMAP TABLE school.student:college.student。

     • テーブル名を student から student2 にリネームし、テーブルが属するデータベースを school から college に変更：REMAP TABLE school.student:college.student2。

     • school のすべてのテーブルを college にリストア：REMAP TABLE school.*:college.*

     説明

     リネームする database_name または table_name に特殊文字が含まれる場合、特殊文字を含む database_name または table_name は、バッククォート（``）で囲む必要があります。

   • remap_tablegroup_list：テーブルが属するテーブルグループをリネームします。ソーステーブルにテーブルグループがバインドされている場合、リストア先のテナントでテーブルを作成する際、システムはデフォルトでテーブルをリストア先のテナントの同名のテーブルグループにリストアします。同名のテーブルグループが存在しない場合、テーブルのリストアは失敗します。リストア先のテナントに他のテーブルグループがある場合は、このステートメントを使用してテーブルを他のテーブルグループにリストアできます。ソースオブジェクトとリネームオブジェクトは、英数字のコロン（:）で接続します。

     例えば、ソーステーブルグループ tg1 のすべてのテーブルをリストア先のテーブルグループ newtg1 にリストアするには、REMAP TABLEGROUP tg1:newtg1 を使用します。

   • remap_tablespace_list：テーブルが属するテーブルスペースをリネームします。テーブルスペースは、OceanBaseデータベースにおいて論理単位として機能し、現在は主にデータ暗号化に使用されます。ソーステーブルにテーブルスペースがバインドされている場合、リストア先のテナントでテーブルを作成する際、システムはデフォルトでテーブルをリストア先のテナントの同名のテーブルスペースにリストアします。同名のテーブルスペースが存在しない場合、テーブルのリストアは失敗します。リストア先のテナントに他のテーブルスペースがある場合は、このステートメントを使用してテーブルを他のテーブルスペースにリストアできます。ソースオブジェクトとリネームオブジェクトは、英数字のコロン（:）で接続します。

     例えば、ソーステーブルスペース ts1 のすべてのテーブルをリストア先のテーブルスペース newts1 にリストアするには、REMAP TABLESPACE ts1:newts1 を使用します。

   テーブル単位のリストア関連パラメータの詳細については、テーブル単位のリストア関連パラメータの紹介を参照してください。

   infodb データベースの tbl1、tbl2 テーブルをリストア先の infodb データベースにリストアし、tbl1 テーブルを newtbl にリネームし、テーブルが属するテーブルグループを newtg1 にリネームし、テーブルが属するテーブルスペースを newts1 にリネームします。例：

   ALTER SYSTEM 
   RECOVER TABLE infodb.tbl1,infodb.tbl2 
   TO TENANT oracle001 
   FROM 'file:///data/nfs/backup/data,file:///data/nfs/backup/archive' 
   UNTIL TIME='2023-09-30 00:00:00' 
   WITH 'pool_list=restore_pool'
   REMAP TABLE infodb.tbl1:newtbl 
   REMAP TABLEGROUP tg1:newtg1
   REMAP TABLESPACE ts1:newts1;
   

次のステップ

• 指定されたテーブルのリストアを開始した後、ビューを使用してテーブルリストアの進捗状況と結果を確認できます。具体的な操作については、テーブルレベルのリストアの進捗状況の確認およびテーブルレベルのリストア結果の確認を参照してください。

• 指定されたテーブルのリストアが完了した後、アシスタントテナントが存在するクラスタで以下のコマンドを実行して、アシスタントテナント用に作成されたリソースプールを手動で解放する必要があります。

  DROP RESOURCE POOL restore_pool;
  

  ここで、restore_poolはリストア前の準備時にアシスタントテナント用に作成されたリソースプールの名前を表します。

  リソースプールの削除に関する詳細な操作については、リソースプールの削除を参照してください。

関連ドキュメント

テーブルレベルのリストアにおける各スキーマ情報のリストア状況については、テーブルレベルのリストアのスキーマリストアの説明を参照してください。