スタンバイテナント作成前の準備|V4.4.2|OceanBaseデータベース|OceanBaseデータベースドキュメント|分散データベース

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

最終更新日：2026-07-30 06:39:47 更新

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

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

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

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

注意

スタンバイテナントのソースを選択した後、スタンバイテナントを作成する前に、そのスタンバイテナントに対応するソーステナント（プライマリテナントまたは別のスタンバイテナント）でログアーカイブを有効にすることをお勧めします。これは、ソーステナントでログアーカイブが有効になっていない場合、スタンバイテナントがソーステナントに遅れたときにソーステナントのログがすでに回収されてしまうと、スタンバイテナントのログ同期が停止してしまう可能性があるためです。ソーステナントでログアーカイブが作成前に有効になっている場合、このような状況が発生した場合、スタンバイテナントはソーステナントのアーカイブログから自動的にそのデータを補完できます。
ソーステナントでログアーカイブを有効にする詳細な操作については、アーカイブモードの開始を参照してください。
ソーステナントのログアーカイブが有効になっていないためにスタンバイテナントのログ同期が停止した場合は、物理スタンバイデータベースの同期プロセスで停止の 問題3：スタンバイデータベースのログ同期状態異常 を参照して調査してください。

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

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