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

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

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

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

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

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

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など）を使用する必要があり、同時にプライマリテナントとスタンバイテナントが存在するクラスタが共有ストレージに同時にアクセスできる必要があります。これはコミュニティエディションのユーザーや単一マシン版のユーザーにとっては使い勝手が悪く、ハードルが高いです。

  上記の理由により、BACKUP DATABASE PLUS ARCHIVELOG機能を使用して、プライマリテナントのすべてのデータとアーカイブ済みログを、ローカル（プライマリテナントが単一マシンの使用シナリオに該当する場合）または共有ストレージ（コミュニティエディションでプライマリテナントがクラスタの使用シナリオに該当する場合）にデータベースのスナップショットを生成できます。このスナップショットにはベースラインデータとデータベースの実行に必要なアーカイブ済みログが含まれています。次に、このスナップショットを、作成予定のスタンバイテナントが存在するクラスタがアクセス可能なメディアにアップロードし、最後にデータベーススナップショットからスタンバイテナントを復元します。

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

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

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

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

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