Experience the multi-tenant feature
The multi-tenant 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, permissions, and resources of tenants are isolated. Each tenant has its own access ports and CPU and memory resources. 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 multi-tenant 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 multi-tenant feature of OceanBase Database, this topic describes how to create tenants and modify their resource configurations.
1. 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 your OceanBase Database as the administrator of the sys tenant and execute the following SQL statement to create a unit config.
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.
- 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 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;
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;
2. 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 step 4.
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');
Note that the above example is for a cluster of nodes. If your cluster has 3 nodes, then the value of zone_list should be ('zone1','zone2','zone3'), where the name of the zone needs to be filled in according to your actual situation.
3. 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='%';
Note that the above example is for a cluster of nodes, and only a single-replica tenant can be created. If your cluster has 3 nodes, the value of zone_list should be ('zone1','zone2','zone3'), and the PRIMARY_ZONE should be filled with 'zone1;zone2;zone3', indicating that the tenant's leader is distributed first in zone1, then in 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.gv$tenant view to verify whether the tenants exist in the cluster.
obclient [oceanbase]> SELECT * FROM oceanbase.gv$tenant;
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 -ur**t@tenant1#ob_test -p
obclient [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| oceanbase |
| information_schema |
| mysql |
| test |
+--------------------+
4 rows in set (0.010 sec)
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 (0.048 sec)
obclient [test]> show tables;
+----------------+
| Tables_in_test |
+----------------+
| t_f1 |
+----------------+
1 row in set (0.001 sec)
Log on to tenant2 and query the test database.
obclient -hXXX.XX.XXX.106 -P2883 -ur**t@tenant2#ob_test -p
obclient [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| oceanbase |
| information_schema |
| mysql |
| test |
+--------------------+
4 rows in set (0.010 sec)
obclient [(none)]> use test;
Database changed
obclient [test]> show tables;
Empty set (0.002 sec)
obclient [test]>
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.
4. 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. In this step, you need to operate as root user in sys tenant:
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, MAX_MEMORY '10G', MIN_CPU=5, MIN_MEMORY='10G';
Query OK, 0 rows affected (0.002 sec)
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 13:40:39.989799 | 1026 | unit1 | 5 | 5 | 10737418240 | 10737418240 | 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, 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 view resource units, resource pools, and tenants in the cluster, and the CPU and memory resources by querying the gv$unit view.
obclient [oceanbase]> SELECT * FROM gv$unit;