OceanBaseデータベースV4.0以降では、システムテナント、ユーザーテナント、および各ユーザーテナントに対応するMetaテナントの3種類のテナントがあります。
4.x以前のバージョンでは、システムテナントとユーザーテナントのみでした。そのため、本来ユーザーテナントに属するはずのデータがシステムテナントに格納される問題が発生し、システムテナントが肥大化し、システムテナントのリソース占有量の増加、リソース統計の粗い粒度、リソース分離の不足などの問題が生じ、クラスタの安定性に大きな課題をもたらしていました。OceanBaseデータベースV4.0からはMetaテナントが導入され、各ユーザーテナントに対応するMetaテナントが配置され、ユーザーテナントのプライベートデータを管理し、ユーザーテナントのリソースを使用します。
Root Serviceは、クラスタ管理、テナント管理、リソース管理、ロードバランシング、日次コンパクションスケジューリング、移行レプリケーションなど、OceanBaseデータベースの多くの管理作業を担当しています。Root Serviceはシステムテナントに基づいて上記の機能をサポートします。システムテナントは、OceanBaseデータベース内部でクラスタの共通タスクを処理するためのデータベースインスタンスです。
テナントタイプの紹介
システムテナント
システムテナントはクラスタがデフォルトで作成するテナントであり、クラスタのライフサイクルと同期しており、クラスタとすべてのテナントのライフサイクルを管理します。システムテナントにはログストリーム1号しかなく、ポイントツーポイントの書き込みのみをサポートし、スケーリング機能はありません。システムテナントではユーザーテーブルを作成でき、すべてのユーザーテーブルとシステムテーブルのデータはログストリーム1号によってサービスされます。システムテナントのデータはクラスタ専用であり、物理バックアップと復旧はサポートされていません。
システムテナントは、アプリケーションシステムがOceanBaseデータベースにアクセスするためのエントリポイントです。クライアントはアプリケーションシステムの設定ファイルを解析した後、Config ServerにアクセスしてシステムテナントのIPリストを取得し、次にシステムテナントにアクセスしてメタデータを段階的に取得し、最終的にターゲットテナントとの接続を確立します。システムテナントの容量は安定性にとって大きな課題であり、多数のアプリケーションシステムが同時に再起動すると、接続確立のためのトラフィックが急増し、短期間でシステムテナントのワーカースレッドを使い果たしてしまい、アプリケーションシステムとターゲットテナントとの接続確立に失敗します。システムテナントには水平スケーリング機能がないため、システムテナントに対しては垂直スケーリングを行うか、クラスタの構成パラメータを調整する必要があります。
システムテナントはマルチレプリカ機構により、少数のノード障害に耐えられるようになっていますが、それでもクラスタの単一ポイントとなります。カーネルのバグによりシステムテナントに異常が発生すると、OceanBaseクラスタのサービス可用性に影響を与え、クライアントが接続を確立できなくなったり、クラスタ内部の管理作業に異常が発生したりします。そのため、システムテナントの安定性はOceanBaseクラスタ全体の安定性にとって非常に重要です。システムは検出メカニズムを備えており、このメカニズムによりシステムテナントの異常を検出し、運用コマンドを用いて強制的にプライマリを切り替えることで復旧します。また、外部のadminツールを用いて強制的にサービスを切り替えることも可能であり、新しいプライマリが就任した後、元の異常マシンを隔離します。
注意
システムテナントはクラスタ管理とテナント管理を目的としており、完全なデータベース機能は提供されていません。本番環境や業務テストなどの場面での使用は推奨されません。
ユーザーテナント
システムテナントに対応するのがユーザーテナントであり、ユーザーが作成するテナントです。外部に対して完全なデータベース機能を提供し、MySQLおよびOracleの両方の互換モードをサポートしています。ユーザーテナントは、複数のマシンにサービス能力を水平スケールでき、動的な拡張と縮小をサポートしており、内部ではユーザーの設定に基づいて自動的にログストリームを作成および削除します。ユーザーテナントのデータは、より強力なデータ保護と可用性要件を持ち、クラスタ間の物理同期や物理バックアップ・復旧をサポートしており、典型的なデータにはスキーマデータ、ユーザーテーブルデータ、トランザクションデータなどが含まれます。
ユーザーテナントの詳細については、ユーザーテナントを参照してください。
Metaテナント
Metaテナントは、OceanBaseデータベース内部で自己管理されるテナントであり、ユーザーテナントが作成されるたびに対応するMetaテナントも作成され、そのライフサイクルはユーザーテナントと同期します。Metaテナントは、ユーザーテナントのテナント専有データを格納および管理するために使用されます。このデータは、構成パラメータ、位置情報、レプリカ情報、ログストリームの状態、バックアップ・復旧関連情報、コンパクション情報など、クラスタ間の物理同期や物理バックアップ・復旧を必要としません。Metaテナントにはログインできず、一般ユーザーはシステムテナントのビューを通じてのみMetaテナント下のデータを照会できます。Metaテナントには独立したユニットがなく、テナント作成時にはデフォルトでMetaテナント用のリソースが予約され、各種リソースはユーザーテナントのリソースから差し引かれます。
ユーザーテナントとMetaテナントは関連する概念であり、簡単に言えば、ユーザーテナントにはユーザーデータに関連する情報が保存されており、ユーザーが作成したテーブルや一部のシステムテーブルが含まれます。このデータはプライマリ/スタンバイクラスタ間で同期する必要があり、物理バックアップ・復旧もこのデータを対象とします。一方、Metaテナントにはユーザーテナントの運用を支えるテナント専有データが保存されており、プライマリ/スタンバイクラスタはそれぞれ独自のMetaテナントを作成します。物理バックアップ・復旧されたテナントにも独自のMetaテナントが存在するため、このデータはプライマリ/スタンバイクラスタ間で同期する必要がなく、バックアップも不要です。システムテナントはMetaテナントと同様に、クラスタの運用を支えるクラスタ専有データを保存しており、同様にプライマリ/スタンバイクラスタ間での同期や物理バックアップも不要です。

上図のように:
- テナントはOceanBaseデータベース内のインスタンスであり、一定の物理リソースを専有しており、クラウド環境下のDockerに似ています。
- システムテナントはクラスタがデフォルトで作成するテナントであり、クラスタのライフサイクルと同期しており、クラスタとすべてのユーザーテナントを管理します。
- ユーザーテナントはユーザーが作成し、ユーザーテナントとMetaテナントは一対一で対応し、同一のライフサイクルを持ちます。
- 専有データとは、クラスタとユーザーテナントの運用を支えるデータを指し、各クラスタとテナントには独自のデータがあります。このデータはプライマリ/スタンバイクラスタ間で同期する必要がなく、物理バックアップも不要です。
- 非専有データとは、ユーザーデータを指し、ユーザーが作成したテーブルや一部のシステムテーブルが含まれ、プライマリ/スタンバイクラスタ間で同期および物理バックアップが必要です。
- システムテナントとMetaテナントにはログストリーム1号しかなく、水平スケーリング機能はありません。
- ユーザーテナントは、ログストリームの動的な作成と削除をサポートしており、水平スケーリング機能を備えています。
テナント情報の照会
システムテナントにログインし、DBA_OB_TENANTSビューを照会することで、すべてのテナントを確認できます。TENANT_TYPEはテナントタイプを表します:SYSはシステムテナント、METAはMetaテナント、USERはユーザーテナントです。テナントIDが1のものがシステムテナントです。テナントIDが1000より大きいテナントのうち、偶数のものがユーザーテナント、奇数のものがMetaテナントであり、ユーザーテナントのテナントIDは対応するMetaテナントよりも1大きいです。
例:
obclient [oceanbase]> SELECT * FROM DBA_OB_TENANTS;
+-----------+-------------+-------------+----------------------------+----------------------------+--------------+---------------+-------------------+--------------------+--------+---------------+--------+-------------+-------------------+------------------+---------------------+---------------------+---------------------+---------------------+--------------+----------------------------+
| TENANT_ID | TENANT_NAME | TENANT_TYPE | CREATE_TIME | MODIFY_TIME | PRIMARY_ZONE | LOCALITY | PREVIOUS_LOCALITY | COMPATIBILITY_MODE | STATUS | IN_RECYCLEBIN | LOCKED | TENANT_ROLE | SWITCHOVER_STATUS | SWITCHOVER_EPOCH | SYNC_SCN | REPLAYABLE_SCN | READABLE_SCN | RECOVERY_UNTIL_SCN | LOG_MODE | ARBITRATION_SERVICE_STATUS |
+-----------+-------------+-------------+----------------------------+----------------------------+--------------+---------------+-------------------+--------------------+--------+---------------+--------+-------------+-------------------+------------------+---------------------+---------------------+---------------------+---------------------+--------------+----------------------------+
| 1 | sys | SYS | 2023-05-17 18:10:19.940353 | 2023-05-17 18:10:19.940353 | RANDOM | FULL{1}@zone1 | NULL | MYSQL | NORMAL | NO | NO | PRIMARY | NORMAL | 0 | NULL | NULL | NULL | NULL | NOARCHIVELOG | DISABLED |
| 1001 | META$1002 | META | 2023-05-17 18:15:21.455549 | 2023-05-17 18:15:36.639479 | zone1 | FULL{1}@zone1 | NULL | MYSQL | NORMAL | NO | NO | PRIMARY | NORMAL | 0 | NULL | NULL | NULL | NULL | NOARCHIVELOG | DISABLED |
| 1002 | mysql001 | USER | 2023-05-17 18:15:21.461276 | 2023-05-17 18:15:36.669988 | zone1 | FULL{1}@zone1 | NULL | MYSQL | NORMAL | NO | NO | PRIMARY | NORMAL | 0 | 1684395321137516636 | 1684395321137516636 | 1684395321052204807 | 4611686018427387903 | NOARCHIVELOG | DISABLED |
| 1003 | META$1004 | META | 2023-05-17 18:18:19.927859 | 2023-05-17 18:18:36.443233 | zone1 | FULL{1}@zone1 | NULL | MYSQL | NORMAL | NO | NO | PRIMARY | NORMAL | 0 | NULL | NULL | NULL | NULL | NOARCHIVELOG | DISABLED |
| 1004 | oracle001 | USER | 2023-05-17 18:18:19.928914 | 2023-05-17 18:18:36.471606 | zone1 | FULL{1}@zone1 | NULL | ORACLE | NORMAL | NO | NO | PRIMARY | NORMAL | 0 | 1684395321137558760 | 1684395321137558760 | 1684395320951813345 | 4611686018427387903 | NOARCHIVELOG | DISABLED |
+-----------+-------------+-------------+----------------------------+----------------------------+--------------+---------------+-------------------+--------------------+--------+---------------+--------+-------------+-------------------+------------------+---------------------+---------------------+---------------------+---------------------+--------------+----------------------------+
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テナントには直接ログインできません。その情報は、ユーザーテナントおよびシステムテナントからアクセス可能です。
|