Tenant types

Three types of tenants are supported in OceanBase Database V4.0 and later: sys tenant, user tenant, and meta tenant.

In versions earlier than V4.x, only two types of tenants exist: sys tenant and user tenant. Data of a user tenant may be mistakenly stored in the sys tenant, resulting in a large amount of data in the sys tenant. This causes a series of issues such as too many resources occupied by the sys tenant, coarse-grained resource statistics, and insufficient resource isolation, thereby causing a great challenge to the stability of the cluster. In OceanBase Database V4.0 and later, a meta tenant is configured for each user tenant to manage the private data of this user tenant. The meta tenant uses the resources of the user tenant.

RootService implements cluster management, tenant management, resource management, load balancing, daily major compaction scheduling, and migration and replication in the sys tenant of OceanBase Database. The sys tenant is a database instance used to process public cluster management tasks within OceanBase Database.

Tenant types

• System tenant (sys tenant)

  The sys tenant is automatically created when you create an OceanBase cluster. Its lifecycle is consistent with that of the cluster. It manages the lifecycles of the cluster and all user tenants in the cluster. The sys tenant has only one log stream with the ID 1, supports only single-point writes, and does not support scaling. You can create user tables in the sys tenant. All user tables and system tables are served by the No.1 log stream. The data of the sys tenant is the private data of the cluster and does not support physical backup or restore.

  Application systems access OceanBase Database from the sys tenant. The client parses the configuration file of the application system and obtains the IP address list of the sys tenant from the Config Server. Then, the client accesses the sys tenant to obtain the metadata and connects to the target tenant. The stability of the sys tenant is challenged by its capacity. When many application systems restart at the same time, the connection establishment requests will produce a traffic peak and exhaust the worker threads of the sys tenant, thereby causing connection establishment failures. The sys tenant does not support horizontal scaling. You can perform vertical scaling or adjust cluster parameters for the sys tenant.

  Though the multi-replica mechanism ensures that the sys tenant can tolerate failures of a minority of nodes, the sys tenant is still a single point in the cluster. If the sys tenant in an OceanBase cluster becomes abnormal due to a kernel bug, the service availability of the cluster is affected, thereby causing connection establishment failures on the client and management exceptions in the cluster. Therefore, the stability of the sys tenant is essential to the stability of the OceanBase cluster. The system provides a detection mechanism for detecting exceptions of the sys tenant. When an exception is detected, you can use O&M commands to forcibly switch the leader role to recover services. You can also use an external admin tool to forcibly switch services to the new leader and then isolate the abnormal server.

  Notice

  The system tenant is intended for cluster management and tenant management, and does not provide full database functionality. It is not recommended for use in production or business testing environments.

• User tenant

  A user tenant is created by a user. A user tenant can provide complete database services and supports MySQL and Oracle modes. A user tenant can distribute its service capabilities on multiple servers and supports dynamic scaling. Log streams are automatically created and deleted based on user configurations. The data of a user tenant, such as the schema data, user table data, and transaction data, requires stronger data protection and higher availability. The physical synchronization and physical backup and recovery of the user tenant data across clusters are supported.

  For more information about user tenants, see User tenants.

• Meta tenant

  Meta tenants are used for internal management in OceanBase Database. When you create a user tenant, a corresponding meta tenant is automatically created. The lifecycle of a meta tenant is the same as that of its user tenant. You can use a Meta tenant to store and manage cluster-related private data of the corresponding user tenant. This private data, such as parameters and information about locations, replicas, log stream status, backup and recovery, and major compaction, does not require cross-database physical synchronization or physical backup and recovery. You cannot log in to a meta tenant. You can only query the data in a meta tenant from views in the sys tenant. A meta tenant has no independent resource units. When a meta tenant is created, resources are reserved for it by default. The resources are deducted from those of the corresponding user tenant.

User tenants and meta tenants are associated. A user tenant stores the data of users, including tables created by users and some system tables. This data must be synchronized between the primary and standby clusters. It is also needed during physical backup and recovery. A meta tenant stores the private data of the cluster to support the running of the corresponding user tenant. Meta tenants are separately created in the primary and standby clusters. A meta tenant will also be created for a user tenant recovered based on the physical backup data. Therefore, the data stored in a meta tenant does not need to be synchronized between the primary and standby clusters or backed up. Like a meta tenant, the sys tenant also stores the private data of the cluster to support the running of the cluster. This data does not need to be synchronized between the primary and standby clusters or physically backed up.

As shown in the preceding figure, the time model includes the following time segments:

• A tenant is an instance in OceanBase Database and exclusively occupies part of the physical resources. It is similar to a Docker container in a cloud environment.
• The sys tenant is created by default for an OceanBase cluster and its lifecycle is consistent with that of the cluster. It manages the lifecycles of the cluster and all user tenants in the cluster.
• A user tenant is created by a user. One user tenant corresponds to one meta tenant, and they have the same lifecycle.
• Private data refers to the data required to support the running of a cluster or user tenant. Each cluster or tenant has its own data, which does not need to be synchronized between the primary and standby clusters or physically backed up.
• Non-private data refers to the user data, including the tables created by users and some system tables. This data must be synchronized between the primary and standby clusters and physically backed up.
• The sys tenant or meta tenant has only one log stream with the ID 1 and does not support scaling.
• You can dynamically create and delete log streams for a user tenant to implement horizontal scaling.

Query tenant information

You can log in to the sys tenant and query the DBA_OB_TENANTS view for information about all tenants. TENANT_TYPE specifies the tenant type. The value SYS indicates the sys tenant, META indicates a meta tenant, and USER indicates a user tenant. The ID of the sys tenant is 1. Among tenants whose IDs are greater than 1000, an even ID number indicates a user tenant, and an odd number indicates a meta tenant. The ID of a user tenant is equal to that of the corresponding meta tenant plus 1.

Here is an example:

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

Differences among different types of tenants

The following table compares the key characteristics of the three types of tenants from the user perspective.