The multitenancy feature of OceanBase Database allows you to create instance resource pools for clusters. Each tenant in OceanBase Database is an instance, which is similar to a MySQL instance. Data, privileges, and resources of a tenant are isolated from those of other tenants. Each tenant has its own access ports and CPU and memory resources.
Background
OceanBase Database allows you to flexibly adjust the CPU and memory resources allocated to a tenant, which is transparent to the upper-layer business system. The multitenancy mechanism allows you to efficiently use OceanBase cluster resources, reduce costs, ensure high availability and performance, and implement on-demand scaling based on your business requirements.
To help you understand the multitenancy feature of OceanBase Database, this topic describes how to create OceanBase tenants and modify their resource configurations.
Create unit configs
In OceanBase Database, a resource unit is the minimum logical unit for a tenant to use CPU and memory resources. It is also the basic unit for cluster scaling and load balancing. When a cluster node goes online or offline or a cluster is scaled in or out, the distribution of resource units on the nodes is dynamically adjusted to balance the resource usage. A unit config is a configuration file that specifies the specifications of the computing and storage resources (including memory, CPU, and I/O resources) required for a resource unit.
Based on the distributed architecture of OceanBase Database, an OceanBase Database tenant can be flexibly defined in different dimensions such as resource specifications, resource pool, replica type, and replica distribution. Therefore, if you want to create a tenant, you must create a unit config, a resource pool, and a tenant in sequence.
You must determine a unit config before you create an OceanBase Database tenant. You can log on to OceanBase Database as the administrator of the sys tenant and execute the following SQL statement to create unit configs.
In this example, unit1 and unit2 are created, and their CPU and memory resources, IOPS, and maximum and minimum thresholds of disk usage are specified.
unit1 is configured with 3 CPU cores and 6 GB of memory. The IOPS and disk size of unit1 are 128 and 10 GB, respectively.
obclient [oceanbase]> CREATE RESOURCE UNIT unit1 MAX_CPU 3, MAX_MEMORY '6G', MAX_IOPS 128,MAX_DISK_SIZE '10G', MAX_SESSION_NUM 64, MIN_CPU=3, MIN_MEMORY='6G', MIN_IOPS=128;unit2 is configured with 4 CPU cores and 8 GB of memory. The IOPS and disk size of unit2 are 128 and 20 GB, respectively.
obclient [oceanbase]> CREATE RESOURCE UNIT unit2 MAX_CPU 4, MAX_MEMORY '8G', MAX_IOPS 128,MAX_DISK_SIZE '20G', MAX_SESSION_NUM 64, MIN_CPU=4, MIN_MEMORY='8G', MIN_IOPS=128;
Create resource pools and associate them with the unit configs
A unit config is a set of configuration specifications for a tenant, whereas a resource pool is a set of entity resources for a tenant. Therefore, in this step, you must create resource pools and associate them with the unit configs.
In this example, pool1 and pool2 are created and associated with unit1 and unit2 respectively. As a result, the resource units are mapped to the resource pools. UNIT_NUM indicates the number of units specified in one zone. In the same tenant, you can allocate at most one unit to each node. ZONE_LIST specifies the zones where the tenant is deployed in the current cluster.
In this example, the OceanBase cluster contains only one node. Therefore, only one unit and one zone list are specified. Before you create a resource pool, make sure that the available resources are sufficient. If the resources are insufficient, you can delete the existing test tenants or decrease the unit configs of the existing tenants. For more information, see Modify tenant configurations and adjust instance resource specifications.
obclient [oceanbase]> CREATE RESOURCE POOL pool1 UNIT='unit1',UNIT_NUM=1,ZONE_LIST=('zone1');
obclient [oceanbase]> CREATE RESOURCE POOL pool2 UNIT='unit2',UNIT_NUM=1,ZONE_LIST=('zone1');
Notice
A single-node cluster is used as an example in the preceding sample code. If your cluster has three nodes, you need to set the value of the
ZONE_LISTparameter in the format of('zone1','zone2','zone3'). Replace 'zone1', 'zone2', and 'zone3' with the actual zone names.
Create tenants based on the created resource pools
After the unit configs and resource pools are created and associated, you can create a tenant.
In this example, the OceanBase cluster contains only one node. Therefore, you can create only a single-replica tenant. If you want to create a three-replica tenant, the OceanBase cluster must contain at least three nodes.
Define a single-replica tenant named tenant1, set the character set to utf8mb4, and set the resource pool to pool1. ob_tcp_invited_nodes specifies the whitelist for the tenant. You can set the initial value to % to allow access from all IP addresses. You can change the value as required later on.
obclient [oceanbase]> CREATE TENANT IF NOT EXISTS tenant1 CHARSET='utf8mb4', ZONE_LIST=('zone1'), PRIMARY_ZONE='zone1', RESOURCE_POOL_LIST=('pool1') SET ob_tcp_invited_nodes='%';
Notice
A single-node cluster is used as an example in the preceding sample code. In this case, you can create only a single-replica tenant. If your cluster has three nodes, you need to set the value of the
ZONE_LISTparameter in the format of ('zone1','zone2','zone3') and thePRIMARY_ZONEparameter to'zone1;zone2;zone3', which indicates that the leader of the tenant is preferentially distributed to zone1 and then zone2.
Likewise, define a single-replica tenant named tenant2, set the character set to utf8mb4, and set the resource pool to pool2.
obclient [oceanbase]> CREATE TENANT IF NOT EXISTS tenant2 CHARSET='utf8mb4', ZONE_LIST=('zone1'), PRIMARY_ZONE='zone1', RESOURCE_POOL_LIST=('pool2') SET ob_tcp_invited_nodes='%';
After you create tenant1 and tenant2, you can query the oceanbase.DBA_OB_TENANTS view to verify whether the tenants exist in the cluster.
obclient [oceanbase]> SELECT * FROM DBA_OB_TENANTS;
After you create tenant1 and tenant2, you can query the oceanbase.DBA_OB_TENANTS view to verify whether the tenants exist in the cluster.
obclient [oceanbase]> SELECT * FROM DBA_OB_TENANTS;
If the preceding statement succeeds, you have created two tenants in the same cluster. Then, you can perform database operations in the tenants.
Log on to tenant1 and create a test table.
obclient -hXXX.XX.XXX.106 -P2883 -uroot@tenant1#ob_test -p******
obclient [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| oceanbase |
| information_schema |
| mysql |
| test |
+--------------------+
4 rows in set
obclient [(none)]> use test;
Database changed
obclient [test]> create table t_f1(id decimal(10,0),id2 decimal(10,0),id3 date,id4 date,id5 float,id6 float,id7 varchar(30),id8 varchar(300));
Query OK, 0 rows affected
obclient [test]> show tables;
+----------------+
| Tables_in_test |
+----------------+
| t_f1 |
+----------------+
1 row in set
Log on to tenant2 and query the test database.
obclient -hXXX.XX.XXX.106 -P2883 -uroot@tenant2#ob_test -p******
obclient [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| oceanbase |
| information_schema |
| mysql |
| test |
+--------------------+
4 rows in set
obclient [(none)]> use test;
Database changed
obclient [test]> show tables;
Empty set
The query results show that the resources, data, and permissions of the two tenants in the cluster are isolated. You can perform more tests to verify the tenant isolation feature of OceanBase Database.
Modify tenant configurations and adjust instance resource specifications
OceanBase Database allows you to flexibly adjust the CPU and memory resources of tenants in real time, which is transparent to the business system. To modify the CPU and memory resources of a tenant, you only need to adjust the unit config used by the tenant, without modifying the resource pool or tenant.
You can check the unit config used by a tenant by querying the __all_unit_config system table.
obclient [oceanbase]> SELECT * FROM oceanbase.__all_unit_config;
+----------------------------+----------------------------+----------------+--------------------------------------+---------+---------+--------------+--------------+----------+----------+---------------+---------------------+
| gmt_create | gmt_modified | unit_config_id | name | max_cpu | min_cpu | max_memory | min_memory | max_iops | min_iops | max_disk_size | max_session_num |
+----------------------------+----------------------------+----------------+--------------------------------------+---------+---------+--------------+--------------+----------+----------+---------------+---------------------+
| 2022-07-05 17:32:17.519436 | 2022-07-05 17:32:17.519436 | 1 | sys_unit_config | 5 | 2.5 | 17179869184 | 12884901888 | 10000 | 5000 | 2608854990848 | 9223372036854775807 |
| 2022-07-10 12:58:33.279509 | 2022-07-10 12:58:33.279509 | 1026 | unit1 | 3 | 3 | 6442450944 | 6442450944 | 128 | 128 | 10737418240 | 64 |
| 2022-07-10 12:58:39.276495 | 2022-07-10 12:58:39.276495 | 1027 | unit2 | 4 | 4 | 8589934592 | 8589934592 | 128 | 128 | 21474836480 | 64 |
+----------------------------+----------------------------+----------------+--------------------------------------+---------+---------+--------------+--------------+----------+----------+---------------+---------------------+
As shown in the preceding example, unit1 is configured with 3 CPU cores and 6 GB of memory.
You can adjust the CPU and memory resources of unit1 to 5 CPU cores and 10 GB of memory.
obclient [oceanbase]> ALTER resource unit unit1 max_cpu =5,min_cpu =5 ,memory_size ='10G';
Query OK, 0 rows affected
obclient [oceanbase]> SELECT * FROM oceanbase.__all_unit_config;
+----------------------------+----------------------------+----------------+-----------------+---------+---------+-------------+---------------+----------+----------+-------------+
| gmt_create | gmt_modified | unit_config_id | name | max_cpu | min_cpu | memory_size | log_disk_size | max_iops | min_iops | iops_weight |
+----------------------------+----------------------------+----------------+-----------------+---------+---------+-------------+---------------+----------+----------+-------------+
| 2022-09-29 17:07:14.647714 | 2022-09-29 17:07:14.647714 | 1 | sys_unit_config | 2.5 | 2.5 | 8589934592 | 8589934592 | 25000 | 25000 | 2 |
| 2022-09-29 18:27:21.231880 | 2022-09-30 10:53:49.522260 | 1004 | unit1 | 5 | 5 | 10737418240 | 51539607552 | 80000 | 80000 | 8 |
+----------------------------+----------------------------+----------------+-----------------+---------+---------+-------------+---------------+----------+----------+-------------+
As shown in the preceding example, the adjustment of the tenant configurations takes effect immediately. After the adjustment, the CPU and memory resources of unit1 are 5 CPU cores and 10 GB of memory. Based on kernel virtualization, OceanBase Database allows the modifications on CPU and memory resources of a tenant to take effect immediately without data migration or switchover. Therefore, the modifications are transparent to your business system.
You can query the DBA_OB_UNITS view to learn of information about resource units, resource pools, tenants in the cluster, and the CPU and memory resource information of the tenants.
obclient [oceanbase]> SELECT * FROM DBA_OB_UNITS;