テナントタイプ

OceanBaseデータベースV4.0以降では、システムテナント、ユーザーテナント、および各ユーザーテナントに対応するMetaテナントの3種類のテナントがあります。

4.x以前のバージョンでは、システムテナントとユーザーテナントのみが存在し、本来はユーザーテナントに属するデータがシステムテナントに格納される問題がありました。これにより、システムテナントが肥大化し、システムテナントのリソース占有量が過剰になったり、リソース統計の粒度が粗くなったり、リソースの隔離が不十分になったりするなどの問題が発生し、クラスタの安定性に大きな課題をもたらしていました。OceanBaseデータベースV4.0からはMetaテナントが導入され、各ユーザーテナントに対応するMetaテナントが割り当てられ、ユーザーテナントのプライベートデータを管理し、ユーザーテナントのリソースを使用します。

Root Serviceは、OceanBaseデータベースの多くの管理作業を担っており、クラスタ管理、テナント管理、リソース管理、ロードバランシング、日次マージのスケジューリング、移行レプリケーションなどが含まれます。Root Serviceはシステムテナントに基づいて上記の機能をサポートします。システムテナントは、OceanBaseデータベース内部でクラスタの共通タスクを処理するためのデータベースインスタンスです。

テナントタイプの紹介

• システムテナント

  システムテナントはクラスタがデフォルトで作成するテナントであり、クラスタのライフサイクルと一致します。クラスタおよびすべてのテナントのライフサイクル管理を担当します。システムテナントには1号ログストリームが1つしかなく、シングルポイント書き込みのみをサポートし、拡張性はありません。システムテナントではユーザーテーブルを作成でき、すべてのユーザーテーブルとシステムテーブルのデータは1号ログストリームによって提供されます。システムテナントのデータはクラスタ専用であり、物理バックアップ・リカバリはサポートされません。

  システムテナントは、アプリケーションシステムがOceanBaseデータベースにアクセスするためのエントリポイントです。クライアントはアプリケーションシステムの設定ファイルを解析した後、Config ServerにアクセスしてシステムテナントのIPリストを取得し、さらにシステムテナントにアクセスしてメタデータを段階的に取得し、最終的に対象テナントとの接続を確立します。システムテナントの容量は安定性にとって大きな課題であり、多数のアプリケーションシステムが同時に再起動すると、接続確立時のトラフィックが急増し、短期間でシステムテナントのワーカースレッドを使い果たしてしまい、結果としてアプリケーションシステムが対象テナントとの接続に失敗することがあります。システムテナントには水平方向の拡張性がないため、システムテナントを垂直方向に拡張するか、クラスタのパラメータを調整することができます。

  マルチレプリカ機構により、システムテナントは少数派ノードの障害を許容できるようになっていますが、システムテナントは依然としてクラスタのシングルポイントです。カーネルのバグによりシステムテナントに異常が発生すると、OceanBaseクラスタのサービス可用性に影響を及ぼし、クライアントが接続を確立できなくなったり、クラスタ内部の管理作業に異常が発生したりします。そのため、システムテナントの安定性はOceanBaseクラスタの安定性にとって極めて重要です。システムは検出機構をサポートしており、この機構によりシステムテナントの異常を検出し、運用コマンドを用いて強制的にプライマリを切り替えることで復旧します。また、外部のadminツールを用いてサービスを強制的に切り替えることも可能です。新しいプライマリが就任した後、元の異常なマシンを隔離します。

  注意

  システムテナントはクラスタ管理とテナント管理を目的としており、完全なデータベース機能は提供されません。本番環境や業務テストなどの場面での使用は推奨されません。

• ユーザーテナント

  システムテナントに対応するのがユーザーテナントです。ユーザーテナントはユーザーが作成するテナントであり、完全なデータベース機能を外部に提供し、MySQLおよびOracleの2種類の互換モードをサポートしています。ユーザーテナントはサービス能力の水平方向への拡張を複数のマシンに対してサポートし、動的な拡張と縮小をサポートします。内部ではユーザーの設定に基づいてログストリームが自動的に作成および削除されます。ユーザーテナントのデータは、データ保護と可用性に関する要件がより厳しく、クラスタ間の物理的同期や物理的バックアップ・リカバリをサポートしています。代表的なデータには、スキーマデータ、ユーザーテーブルデータ、トランザクションデータなどが含まれます。

  ユーザーテナントの詳細については、ユーザーテナントを参照してください。

• Metaテナント

  MetaテナントはOceanBaseデータベース内部で自己管理されるテナントです。ユーザーテナントが作成されるたびに、対応するMetaテナントが作成され、そのライフサイクルはユーザーテナントと一致します。Metaテナントは、ユーザーテナントのテナント専用データの格納および管理に使用されます。このデータは、パラメータ、位置情報、レプリカ情報、ログストリームの状態、バックアップ・リカバリ関連情報、メジャーコンパクション情報など、クロスデータベースの物理的同期や物理的バックアップ・リカバリを必要としません。Metaテナントにはログインできず、通常のユーザーはシステムテナントのビューを通じてのみMetaテナント内のデータを照会できます。Metaテナントには独立したUnitがなく、テナント作成時にはデフォルトでMetaテナント用のリソースが予約され、各種リソースはユーザーテナントのリソースから差し引かれます。

ユーザーテナントとMetaテナントは関連する概念であり、簡単に言えば以下のように理解できます：ユーザーテナントに保存されるのは、ユーザーデータに関連する情報であり、ユーザーが作成したテーブルや一部のシステムテーブルが含まれます。このデータはプライマリ/スタンバイクラスタ間で同期する必要があり、物理的バックアップ・リカバリでも操作が必要です。一方、Metaテナントに保存されるのは、ユーザーテナントの運用を支えるテナント専用データです。プライマリ/スタンバイクラスタはそれぞれ独自のMetaテナントを作成し、物理的バックアップデータから復元されたテナントも独自のMetaテナントを持ちます。そのため、このデータはプライマリ/スタンバイクラスタ間で同期する必要がなく、バックアップも不要です。システムテナントはMetaテナントと同様で、クラスタの運用を支えるクラスタ専用データを保存しており、同様にプライマリ/スタンバイクラスタ間での同期や物理的バックアップも不要です。

上図のように：

• テナントはOceanBaseデータベース内のインスタンスであり、一定の物理リソースを専有します。これはクラウド環境下のDockerに似ています。
• システムテナントはクラスタがデフォルトで作成するテナントであり、クラスタのライフサイクルと一致します。クラスタおよびすべてのユーザーテナントの管理を担当します。
• ユーザーテナントはユーザーが作成し、ユーザーテナントはMetaテナントと一対一で対応し、同じライフサイクルを持ちます。
• 専用データとは、クラスタとユーザーテナントの運用を支えるデータを指します。各クラスタとテナントには独自のデータがあり、このデータはプライマリ/スタンバイクラスタ間で同期する必要がなく、物理的バックアップも不要です。
• 非専用データとはユーザーデータを指し、ユーザーが作成したテーブルや一部のシステムテーブルが含まれます。これらはプライマリ/スタンバイクラスタ間で同期および物理的バックアップが必要です。
• システムテナントとMetaテナントには1号ログストリームが1つしかなく、水平方向の拡張性はありません。
• ユーザーテナントはログストリームの動的な作成と削除をサポートし、水平方向の拡張性を備えています。

テナント情報のクエリ

システムテナントにログインし、DBA_OB_TENANTS ビューをクエリすると、すべてのテナントを確認できます。TENANT_TYPE はテナントタイプを表します：SYS はシステムテナント、META はMetaテナント、USER はユーザーテナントです。テナントIDが1のものがシステムテナントです。テナントIDが1000より大きいテナントのうち、偶数のものがユーザーテナント、奇数のものがMetaテナントであり、ユーザーテナントのテナントIDは対応するMetaテナントより1大きくなっています。

例：

obclient(root@sys)[oceanbase]> SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE, CREATE_TIME, PRIMARY_ZONE, LOCALITY, COMPATIBILITY_MODE, STATUS FROM oceanbase.DBA_OB_TENANTS;

クエリ結果は次のとおりです：

+-----------+-------------+-------------+----------------------------+--------------+----------------------------------------------+--------------------+--------+
| TENANT_ID | TENANT_NAME | TENANT_TYPE | CREATE_TIME                | PRIMARY_ZONE | LOCALITY                                     | COMPATIBILITY_MODE | STATUS |
+-----------+-------------+-------------+----------------------------+--------------+----------------------------------------------+--------------------+--------+
|         1 | sys         | SYS         | 2025-12-29 15:43:42.930290 | RANDOM       | FULL{1}@zone1                                | MYSQL              | NORMAL |
|      1001 | META$1002   | META        | 2025-12-29 15:44:48.700796 | zone1;zone2  | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3  | MYSQL              | NORMAL |
|      1002 | mysql001    | USER        | 2025-12-29 15:44:48.704354 | zone1;zone2  | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3  | MYSQL              | NORMAL |
|      1003 | META$1004   | META        | 2025-12-29 15:50:35.033311 | zone1        | FULL{1}@zone1                                | MYSQL              | NORMAL |
|      1004 | oracle001   | USER        | 2025-12-29 15:50:35.034367 | zone1        | FULL{1}@zone1                                | ORACLE             | NORMAL |
+-----------+-------------+-------------+----------------------------+--------------+----------------------------------------------+--------------------+--------+
5 rows in set

テナントタイプの違い

ユーザーの視点から見た、3種類のテナントの主な特性の共通点と相違点は以下のとおりです。