Plan resources

Before you perform a scale-in or scale-out operation on a tenant, you can plan resources for the tenant based on its resource usage and scaling plan.

Scale out resources for a tenant

You can increase the number of resource units or primary zones to scale out resources for a tenant. During scale-out, you can create log streams to implement load balancing, which requires more resources. Therefore, you must check whether the resources in the resource units meet the requirements before the scale-out.

1. Log on to the sys tenant of the cluster as the root user.

   obclient -h172.30.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -A
   

2. Access the database named oceanbase.

   obclient> USE oceanbase;
   

3. Query the usage of logical resources in each resource unit of the tenant.

   obclient [oceanbase]> SELECT * FROM oceanbase.GV$OB_TENANT_RESOURCE_LIMIT WHERE TENANT_ID=1002;
   

   The query result is as follows:

   +----------------+----------+-----------+-------+---------------+---------------------+-----------------+----------------+-------------+----------------------+
   | SVR_IP         | SVR_PORT | TENANT_ID | ZONE  | RESOURCE_NAME | CURRENT_UTILIZATION | MAX_UTILIZATION | RESERVED_VALUE | LIMIT_VALUE | EFFECTIVE_LIMIT_TYPE |
   +----------------+----------+-----------+-------+---------------+---------------------+-----------------+----------------+-------------+----------------------+
   | 172.xx.xxx.xxx |     2882 |      1002 | zone1 | ls            |                   2 |               2 |              0 |          13 | memory               |
   | 172.xx.xxx.xxx |     2882 |      1002 | zone1 | tablet        |                 668 |             668 |              0 |      100000 | configuration        |
   +----------------+----------+-----------+-------+---------------+---------------------+-----------------+----------------+-------------+----------------------+
   2 rows in set
   

   The first line of the query result shows information about log streams of user tenant 1002 on OBServer node 172.xx.xxx.xxx:2882. CURRENT_UTILIZATION indicates that the tenant currently has two log streams. MAX_UTILIZATION indicates that the maximum number of concurrent log streams for the tenant has been 2 so far. LIMIT_VALUE indicates that at most 13 log streams can be created for the tenant. memory indicates that this limit value is calculated based on the memory size of the tenant.

   The second line of the query result shows information about tablets of user tenant 1002 on OBServer node 172.xx.xxx.xxx:2882. CURRENT_UTILIZATION indicates that the tenant currently has 668 tablets. MAX_UTILIZATION indicates that the maximum number of concurrent tablets for the tenant has been 668 so far. LIMIT_VALUE indicates that at most 100,000 tablets can be created for the tenant. configuration indicates that this limit value is calculated based on the parameter configuration of the tenant.

4. Calculate the amount of logical resources required after the scale-out based on the scenario.

   In OceanBase Database, you can calculate the numbers of log streams and tablets for a tenant by using the following formulas:

   • The number of log streams of a user tenant on a single OBServer node in the stable state is calculated as follows:

     • When the user tenant has broadcast log streams: Number of resource units * Number of primary zones + 2

     • When the user tenant has no broadcast log stream: Number of resource units * Number of primary zones + 1

   • Any log stream can transfer partitions to other log streams. A partition transfer between log streams on the same OBServer node does not create log streams, and a partition transfer between log streams across OBServer nodes creates a log stream. If partitions are transferred, the maximum number of temporary log streams supported for a user tenant can be calculated by using the following formula: (Number of resource units * Number of primary zones) * [(Number of resource units -1) * Number of primary zones].

   • If partitions are transferred, the maximum number of log streams supported on a single OBServer node can be calculated by using the following formula: Number of resource units * Number of primary zones * Number of primary zones - Number of primary zones * Number of primary zones + Number of primary zones + 2.

   • The maximum number of tablets that you can create for a tenant on each OBServer node is calculated as follows:

     • When the maximum number is subject to the parameter configuration: (MEMORY_SIZE/1 GB) * _max_tablet_cnt_per_gb

     • When the maximum number is subject to the memory size of the tenant: (MEMORY_SIZE * _storage_meta_memory_limit_percentage)/200 MB * 20000

   For more information about the parameters in the preceding formulas, see View tenant and resource information.

   Assume that tenant 1002 has broadcast log streams and has one primary zone and two resource units. If you want to change the number of primary zones of the tenant to 3, the number of log streams on a single OBServer node is 8, which is calculated by using the following formula: 2 * 3 + 2. If partitions are transferred between the log streams, the maximum number of concurrent log streams specified by the MAX_UNTILIZATION parameter can reach 14. Therefore, you must scale out resources for the tenant to support 14 log streams.

5. Determine the physical resources or parameters to be modified based on the limits on the logical resources.

   The amount of logical resources that you can create for a tenant on each OBServer node is limited by the amount of physical resources or the values of specific parameters. You can query the GV$OB_TENANT_RESOURCE_LIMIT_DETAIL view for the limits on the logical resources of the tenant and the maximum value of each limit.

   obclient [oceanbase]> SELECT * FROM oceanbase.GV$OB_TENANT_RESOURCE_LIMIT_DETAIL WHERE TENANT_ID=1002;
   

   The query result is as follows:

   +----------------+----------+-----------+---------------+---------------+---------------------+
   | SVR_IP         | SVR_PORT | TENANT_ID | RESOURCE_NAME | LIMIT_TYPE    | LIMIT_VALUE         |
   +----------------+----------+-----------+---------------+---------------+---------------------+
   | 172.xx.xxx.xxx |     2882 |      1002 | ls            | configuration |                  90 |
   | 172.xx.xxx.xxx |     2882 |      1002 | ls            | memstore      | 9223372036854775807 |
   | 172.xx.xxx.xxx |     2882 |      1002 | ls            | memory        |                  13 |
   | 172.xx.xxx.xxx |     2882 |      1002 | ls            | data_disk     | 9223372036854775807 |
   | 172.xx.xxx.xxx |     2882 |      1002 | ls            | clog_disk     |                  32 |
   | 172.xx.xxx.xxx |     2882 |      1002 | ls            | cpu           | 9223372036854775807 |
   | 172.xx.xxx.xxx |     2882 |      1002 | tablet        | configuration |              100000 |
   | 172.xx.xxx.xxx |     2882 |      1002 | tablet        | memstore      | 9223372036854775807 |
   | 172.xx.xxx.xxx |     2882 |      1002 | tablet        | memory        |              102400 |
   | 172.xx.xxx.xxx |     2882 |      1002 | tablet        | data_disk     | 9223372036854775807 |
   | 172.xx.xxx.xxx |     2882 |      1002 | tablet        | clog_disk     | 9223372036854775807 |
   | 172.xx.xxx.xxx |     2882 |      1002 | tablet        | cpu           | 9223372036854775807 |
   +----------------+----------+-----------+---------------+---------------+---------------------+
   12 rows in set
   

   The query result shows that the maximum number of log streams that you can create for tenant 1002 on OBServer node 172.xx.xxx.xxx:2882 is subject to the following limits: If the limit type is configuration, you can create at most 90 log streams. If the limit type is memory, you can create at most 13 log streams. If the limit type is clog_disk, you can create at most 32 log streams. The maximum number of tablets that you can create is subject to the following limits: If the limit type is configuration, you can create at most 100,000 tablets. If the limit type is memory, you can create at most 102,400 tablets.

   You can determine the physical resources to be modified based on the preceding limits. For example, if you want a single OBServer node to support up to 14 log streams, you must modify memory and clog_disk.

6. Calculate the amount of physical resources required by a single OBServer node based on the amount of logical resources required after the scale-out.

   Assume that a single OBServer node needs to support up to 14 temporary log streams and up to 40,000 tablets after the scale-out. A sample statement for calculating the physical resources required is as follows:

   obclient [oceanbase]> CALL DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_LOGIC_RES("LS:14, TABLET:40000");
   

   The calculation result is as follows:

   +------------------------+------------+
   | PHYSICAL_RESOURCE_NAME | MIN_VALUE  |
   +------------------------+------------+
   | memstore               |          0 |
   | memory                 | 5553258496 |
   | data_disk              |          0 |
   | clog_disk              | 7516192768 |
   | cpu                    |          0 |
   +------------------------+------------+
   5 rows in set
   

7. Upgrade the unit config for the tenant based on the calculation result. For more information, see Modify the unit config for a tenant.

Scale in resources for a tenant

If you want to scale in resources for a tenant, you can estimate the amount of logical resources required for business operations the same way as in the preceding scale-out scenario. Then you can call the CALCULATE_MIN_PHY_RES_NEEDED_BY_LOGIC_RES subprogram in the DBMS_OB_LIMIT_CALCULATOR package to calculate the amount of physical resources required for the logical resources and downgrade the unit config for the tenant based on your business needs.

Resource units with the same UNIT_GROUP_ID across zones form a unit group. Assume that the tenant has multiple unit groups and all unit groups are idle. If you want to decrease the number of resource units for the tenant, you can perform the following steps to delete a unit group:

1. Log on to the sys tenant of the cluster as the root user.

   obclient -h172.30.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -A
   

2. Access the database named oceanbase.

   obclient> USE oceanbase;
   

3. Query result units of the tenant to be scaled in.

   obclient> SELECT * FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1002;
   

   The query result is as follows:

   +---------+-----------+--------+------------------+---------------+----------------------------+----------------------------+-------+----------------+----------+---------------------+-----------------------+----------------+----------------+---------+---------+-------------+---------------+---------------------+---------------------+-------------+
   | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | CREATE_TIME                | MODIFY_TIME                | ZONE  | SVR_IP         | SVR_PORT | MIGRATE_FROM_SVR_IP | MIGRATE_FROM_SVR_PORT | MANUAL_MIGRATE | UNIT_CONFIG_ID | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE | MAX_IOPS            | MIN_IOPS            | IOPS_WEIGHT |
   +---------+-----------+--------+------------------+---------------+----------------------------+----------------------------+-------+----------------+----------+---------------------+-----------------------+----------------+----------------+---------+---------+-------------+---------------+---------------------+---------------------+-------------+
   |    1016 |      1002 | ACTIVE |             1003 |          1006 | 2024-05-13 11:06:38.569419 | 2024-05-13 14:01:30.069547 | zone1 | xxx.xx.xxx.194 |     2882 | NULL                |                  NULL | NULL           |           1002 |       1 |       1 |  5368709120 |   16106127360 | 9223372036854775807 | 9223372036854775807 |           1 |
   |    1017 |      1002 | ACTIVE |             1003 |          1007 | 2024-05-13 11:06:38.571540 | 2024-05-13 11:06:51.030929 | zone1 | xxx.xx.xxx.198 |     2882 | NULL                |                  NULL | NULL           |           1002 |       1 |       1 |  5368709120 |   16106127360 | 9223372036854775807 | 9223372036854775807 |           1 |
   |    1018 |      1002 | ACTIVE |             1003 |          1006 | 2024-05-13 11:06:38.573614 | 2024-05-13 14:01:30.070603 | zone2 | xxx.xx.xxx.192 |     2882 | NULL                |                  NULL | NULL           |           1002 |       1 |       1 |  5368709120 |   16106127360 | 9223372036854775807 | 9223372036854775807 |           1 |
   |    1019 |      1002 | ACTIVE |             1003 |          1007 | 2024-05-13 11:06:38.575723 | 2024-05-13 11:06:51.030929 | zone2 | xxx.xx.xxx.196 |     2882 | NULL                |                  NULL | NULL           |           1002 |       1 |       1 |  5368709120 |   16106127360 | 9223372036854775807 | 9223372036854775807 |           1 |
   |    1020 |      1002 | ACTIVE |             1003 |          1006 | 2024-05-13 11:06:38.579946 | 2024-05-13 14:01:30.070603 | zone3 | xxx.xx.xxx.204 |     2882 | NULL                |                  NULL | NULL           |           1002 |       1 |       1 |  5368709120 |   16106127360 | 9223372036854775807 | 9223372036854775807 |           1 |
   |    1021 |      1002 | ACTIVE |             1003 |          1007 | 2024-05-13 11:06:38.581002 | 2024-05-13 11:06:51.031986 | zone3 | xxx.xx.xxx.197 |     2882 | NULL                |                  NULL | NULL           |           1002 |       1 |       1 |  5368709120 |   16106127360 | 9223372036854775807 | 9223372036854775807 |           1 |
   +---------+-----------+--------+------------------+---------------+----------------------------+----------------------------+-------+----------------+----------+---------------------+-----------------------+----------------+----------------+---------+---------+-------------+---------------+---------------------+---------------------+-------------+
   6 rows in set
   

   The query result shows that the tenant to be scaled in has two resource units in each zone. Resource units whose UNIT_ID values are respectively 1016, 1018, and 1020 form the unit group whose UNIT_GROUP_ID value is 1006. Resource units whose UNIT_ID values are respectively 1017, 1019, and 1021 form the unit group whose UNIT_GROUP_ID value is 1007.

4. Calculate the minimum amount of physical resources required for the tenant in each resource unit within each unit group.

   For example, calculate the minimum amount of physical resources required for the tenant in each resource unit within the unit groups whose UNIT_GROUP_ID values are respectively 1006 and 1007. The unit group whose UNIT_GROUP_ID value is 1006 corresponds to OBServer nodes xxx.xx.xxx.194:2882, xxx.xx.xxx.192:2882, and xxx.xx.xxx.204:2882. The unit group whose UNIT_GROUP_ID value is 1007 corresponds to OBServer nodes xxx.xx.xxx.198:2882, xxx.xx.xxx.196:2882, and xxx.xx.xxx.197:2882.

   A sample statement for calculating the minimum amount of physical resources required for user tenant 1002 in each resource unit on OBServer node xxx.xx.xx.192:2882 is as follows:

   obclient [oceanbase]> CALL DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_UNIT(TENANT_ID => 1002, SERVER => "xxx.xx.xx.192:2882");
   

   The execution result is as follows:

   +----------------+----------+-----------+------------------------+------------+
   | SVR_IP         | SVR_PORT | TENANT_ID | PHYSICAL_RESOURCE_NAME | MIN_VALUE  |
   +----------------+----------+-----------+------------------------+------------+
   | xxx.xx.xxx.192 |     2882 |      1002 | memstore               |          0 |
   | xxx.xx.xxx.192 |     2882 |      1002 | memory                 | 4294967296 |
   | xxx.xx.xxx.192 |     2882 |      1002 | data_disk              |          0 |
   | xxx.xx.xxx.192 |     2882 |      1002 | clog_disk              | 1073741824 |
   | xxx.xx.xxx.192 |     2882 |      1002 | cpu                    |          0 |
   +----------------+----------+-----------+------------------------+------------+
   5 rows in set
   

   After you calculate the minimum amount of physical resources required for the tenant in each resource unit within each unit group, select the unit group that requires the least resources and delete it.

References

• View tenant and resource information

• Modify the unit config for a tenant

• Modify the number of resource units for a tenant

• Modify the number of primary zones for a tenant