スタンバイテナント作成前の準備

テナントを作成する前に、スタンバイテナントのソースを選択し、作成するスタンバイテナントの数を明確にし、スタンバイテナントの作成方法を選択して、スタンバイテナントのリソース準備を行う必要があります。

スタンバイテナントのソースを選択する

スタンバイテナントは、プライマリテナントからログを同期することも、別のスタンバイテナントからログを同期することもできます。後者のように、別のスタンバイテナントからログを同期するデプロイメントアーキテクチャは、カスケードスタンバイデータベースまたはカスケードスタンバイテナントと呼ばれます。

ビジネスの実際の状況に応じて、スタンバイテナントのソースを選択できます。

作成するスタンバイテナントの数を選択する

OceanBaseデータベースの現行バージョンでは、1つのプライマリテナント（またはスタンバイテナント）が同期できるスタンバイテナントの数に制限はありません。

ログアーカイブに基づくフィジカル・スタンバイ・データベースのシナリオでは、ログの同期はストレージメディアに依存するため、実際のビジネスニーズに基づいて、いくつのテナントを作成するかを決定する必要があります。

ネットワークに基づくフィジカル・スタンバイ・データベースのシナリオでは、スタンバイテナントがログを同期する際にソーステナントのログを読み取るため、ソーステナントのCPU、メモリ、I/Oリソースを消費し、同時にスタンバイテナントとソーステナント間のネットワーク帯域幅リソースも消費します。したがって、スタンバイテナントを作成する際には、ソーステナントのリソース使用状況と実際のビジネスニーズを組み合わせて、いくつのスタンバイテナントを作成するかを決定する必要があります。

スタンバイテナントの作成方法の選択

OceanBaseデータベースでは、スタンバイテナントを作成するための3つの方法が提供されています。実際のビジネスシナリオに応じて、適切な方法でスタンバイテナントを作成できます。

• 空のスタンバイテナントの作成

  プライマリテナントが新しく作成されたばかりの場合、またはユーザーがプライマリテナントが存在するクラスタやログアーカイブメディアに、そのプライマリテナントの作成後の完全なログが保存されていることを確認できる場合、スタンバイテナントの作成時にログ以外の他のベースラインデータやダンプデータに依存する必要はありません。この場合、CREATE STANDBY TENANT ステートメントを使用してスタンバイテナントを作成できます。

  プライマリテナントが完全なログを持っているかどうかを確認する方法は以下のとおりです：

  1. 管理者ユーザーがプライマリテナント、またはプライマリテナントが属するクラスタの sys テナントにログインします。

  2. 以下のコマンドを実行して、プライマリテナント上のログストリームの比較情報を確認します。

     • プライマリテナントが属するクラスタの sys テナントからプライマリテナントのログストリームの比較情報を照会します。

       (SELECT LS_ID FROM oceanbase.CDB_OB_LS_HISTORY WHERE TENANT_ID = xxxx) EXCEPT (SELECT LS_ID FROM oceanbase.CDB_OB_LS WHERE TENANT_ID = xxxx);
       

       または

       (SELECT LS_ID FROM oceanbase.CDB_OB_LS_HISTORY WHERE TENANT_ID = xxxx) MINUS (SELECT LS_ID FROM oceanbase.CDB_OB_LS WHERE TENANT_ID = xxxx);
       

       ここで、プライマリテナントの TENANT_ID は DBA_OB_TENANTS ビューから取得できます。

     • プライマリテナントが自身のテナントを照会します。

       MySQL モード

       Oracleモード

       (SELECT LS_ID FROM oceanbase.DBA_OB_LS_HISTORY) EXCEPT (SELECT LS_ID FROM oceanbase.DBA_OB_LS);
       

       または

       (SELECT LS_ID FROM oceanbase.DBA_OB_LS_HISTORY) MINUS (SELECT LS_ID FROM oceanbase.DBA_OB_LS);
       

       (SELECT LS_ID FROM SYS.DBA_OB_LS_HISTORY) MINUS (SELECT LS_ID FROM SYS.DBA_OB_LS);
       

     ここで、DBA_OB_LS_HISTORY または CDB_OB_LS_HISTORY ビューは、テナント上で作成されたすべてのログストリームを表示するために使用されます。DBA_OB_LS または CDB_OB_LS ビューは、テナント上で現在サービスを提供しているログストリームを表示するために使用されます。2つの SELECT クエリの結果の差分は、プライマリテナント上で作成された後、ロードバランシングやスケーリングなどの理由により削除されたログストリームを示します。

     上記のステートメントの実行結果が空でない場合、プライマリテナント上でログストリームが作成された後に削除されたことを意味し、この場合プライマリテナント上のログは不完全であり、CREATE STANDBY TENANT ステートメントを使用してスタンバイテナントを作成することはできません。クエリ結果が空の場合、次のステップのチェックに進みます。

  3. 以下のコマンドを実行して、プライマリテナント上のログストリーム情報を確認します。

     • プライマリテナントが属するクラスタの sys テナントからプライマリテナントのログストリーム情報を照会します。

       SELECT LS_ID, BEGIN_LSN FROM oceanbase.GV$OB_LOG_STAT WHERE TENANT_ID = xxxx AND ROLE = 'LEADER' ;
       

       ここで、プライマリテナントの TENANT_ID は DBA_OB_TENANTS ビューから取得できます。

     • プライマリテナントが自身のテナントを照会します。

       MySQLモード

       Oracleモード

       SELECT LS_ID, BEGIN_LSN FROM oceanbase.GV$OB_LOG_STAT WHERE ROLE = 'LEADER' ;
       

       SELECT LS_ID, BEGIN_LSN FROM SYS.GV$OB_LOG_STAT WHERE ROLE = 'LEADER' ;
       

     クエリ結果の例は以下のとおりです：

     +-------+-----------+
     | LS_ID | BEGIN_LSN |
     +-------+-----------+
     |     1 |         0 |
     |  1001 |         0 |
     +-------+-----------+
     2 rows in set
     

     ここで、BEGIN_LSN は現在のログストリームレプリカに保存されている最も古いログのLSN(Log Sequence Number)を表します。BEGIN_LSN の値が 0 の場合、現在のログストリームレプリカは作成以来の完全なログを持っていることを意味します。

     クエリ結果に基づいて、ログストリームレプリカに対応する BEGIN_LSN の値が 0 の場合、現在のログストリームレプリカは作成以来の完全なログを持っていることを意味します。テナントのすべてのログストリームレプリカに対応する BEGIN_LSN の値がすべて 0 の場合、そのテナントのすべてのログストリームは完全なログを持っていることを意味し、CREATE STANDBY TENANT ステートメントを使用して空のスタンバイテナントを作成できます。

• 物理バックアップ復旧（ログ付き）機能を使用してスタンバイテナントを作成する

  この方法は、任意のシナリオに適用可能な一般的なスタンバイテナント作成方法です。物理バックアップ復旧の詳細と操作については、物理バックアップ復旧の概要を参照してください。

• BACKUP DATABASE PLUS ARCHIVELOG機能を使用してスタンバイテナントを作成する

  通常の物理バックアップ復旧（ログ付き）機能を使用してスタンバイテナントを作成する場合、データバックアップとログアーカイブを保存するために共有ストレージ（例えば、OSS、NFSなど）を使用する必要があり、同時にプライマリテナントとスタンバイテナントが属するクラスタが共有ストレージに同時にアクセスできることが求められます。これはCommunity EditionユーザーやStandalone Editionユーザーにとって非常に使いにくく、ハードルが高いです。

  上記の理由に基づき、BACKUP DATABASE PLUS ARCHIVELOG機能を使用して、プライマリテナントのすべてのデータとアーカイブログをローカル（プライマリテナントがStandaloneの場合）または共有ストレージ（Community Editionでプライマリテナントがクラスタの場合）にデータベースのスナップショットを生成します。このスナップショットにはベースラインデータとデータベースの運用に必要なアーカイブログが含まれています。次に、このスナップショットを作成予定のスタンバイテナントが属するクラスタがアクセス可能なメディアにアップロードし、最後にデータベーススナップショットを使用してスタンバイテナントを復旧します。

スタンバイテナントのリソース準備

スタンバイテナントを作成する前に、スタンバイテナントに割り当てるリソースプールを決定し、CPU、メモリ、ログディスク容量、IOPSなどのリソースを計画するとともに、スタンバイテナントのレプリカ数、プライマリゾーン、ローカリティなどの情報を決定する必要があります。

スタンバイテナントで使用されるテナントリソースは、プライマリテナントと完全に同一である必要はありません。利用に際しては、業務の実際の状況やプライマリ・スタンバイテナントが担う業務負荷を踏まえ、スタンバイテナントに適切なリソース仕様を選択することを推奨します。プライマリテナントおよび作成予定のスタンバイテナントのユニット数に基づき、以下のコマンドを使用して、スタンバイテナントの各ユニットに必要な物理リソース量を計算できます。

プライマリテナントのTENANT_IDが1002で、作成予定のスタンバイテナントのユニット数が2であると仮定した場合、プライマリテナントが属するクラスタのsysテナントからクラスタにログインした後、スタンバイテナント上の各ユニットに必要な物理リソース量を計算するステートメントは次のとおりです：

obclient [oceanbase]> CALL DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_STANDBY_TENANT(PRIMARY_TENANT_ID => 1002, STANDBY_TENANT_UNIT_NUM => 2);

結果は次のとおりです：

+------------------------+------------+
| PHYSICAL_RESOURCE_NAME | MIN_VALUE  |
+------------------------+------------+
| memstore               |          0 |
| memory                 | 4294967296 |
| data_disk              |          0 |
| clog_disk              | 2147483648 |
| cpu                    |          0 |
+------------------------+------------+
5 rows in set