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テナントのIDより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種類のテナントの主要な特性の相違点と共通点は以下のとおりです:
比較項目 |
システムテナント |
ユーザーテナント |
Metaテナント |
|---|---|---|---|
| テナントID(TENANT_ID) | 1 | 最小値:1002 | 最小値:1001 ユーザーテナントIDとの関係:MetaテナントID + 1 = ユーザーテナントID |
| テナントタイプ(TENANT_TYPE) | SYS | USER | META |
| テナント名規則 | SYS | 大小文字の英字、数字、アンダースコア | META${user_tenant_id}、例:ユーザーテナントのテナントIDが1002の場合、Metaテナント名は:META$1002 |
| データ属性 | クラスタプライベートデータ | テナントネイティブデータ | テナントプライベートデータ |
| 拡張性 | データは水平スケーラブルではなく、ログストリームは1つしかない | 水平スケーラビリティがあり、動的な拡張と縮小をサポートする | データは水平スケーラブルではなく、ログストリームは1つしかない |
| テナント運用 |
|
|
|
| データ外部アクセスインターフェース | システムテナントのビュー。 |
|
Metaテナントには直接ログインできません。その情報は、ユーザーテナントおよびシステムテナントを通じてアクセスできます。
|