租户扩缩容资源规划

在对租户进行扩缩容操作前，可以根据租户当前的资源使用情况以及扩缩容计划，进行资源规划。

调大 Unit number 或增加 Primary Zone 等租户扩容场景

对于调大 Unit number 或增加 Primary Zone 等租户扩容场景，在扩容时，可能会通过新建日志流来实现数据均衡，而新建日志流需要更多的资源，故在扩容前需要提前确认 Unit 资源是否符合要求。

1. 使用 root 用户登录到集群的 sys 租户。

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

2. 进入 oceanbase 数据库。

   obclient> USE oceanbase;
   

3. 查看租户在每个 Unit 上逻辑资源的使用情况。

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

   查询结果如下：

   +----------------+----------+-----------+-------+---------------+---------------------+-----------------+----------------+-------------+----------------------+
   | 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
   

   从第一行结果可知，用户租户 1002 在 172.xx.xxx.xxx:2882 节点上，当前有 2 个日志流（CURRENT_UTILIZATION），曾经同时存在过最多 2 个日志流（MAX_UTILIZATION），最大可以创建 13 个日志流（LIMIT_VALUE），并且这 13 个日志流的上限值由租户内存（memory）计算得来。

   从第二行结果可知，用户租户 1002 在 172.xx.xxx.xxx:2882 节点上，当前有 668 个 TABLET（CURRENT_UTILIZATION），曾经同时存在过最多 668 个 TABLET（MAX_UTILIZATION），最大可以创建 100000 个 TABLET（LIMIT_VALUE），并且这 100000 个 TABLET 的上限值是根据配置项值（configuration）计算得来。

4. 根据实际扩容场景，计算扩容后所需的逻辑资源。

   在 OceanBase 数据库中，租户 LS 和 Tablet 相关的计算公式如下：

   • 用户租户所有节点上达到稳定状态的日志流个数

     • 当前用户租户有广播日志流时：U * P + 2

     • 当前用户租户没有广播日志流时：U * P + 1

   • 由于任何一个日志流都可能将分区 Transfer 到其他日志流上，同一个节点内的日志流之间 Transfer 时不会新建日志流，不同节点的日志流之间 Transfer 时会新建一个日志流。发生 Transfer 时，用户租户最大的临时日志流个数：(U * P) * ((U - 1) * P)

   • 发生 Transfer 时，单个节点上的最大日志流个数：((U * P) * ((U - 1) * P)) / U + (P + 2)

   • 用户租户在每个节点上能够创建 Tablet 个数的上限

     • 受配置项值限制的上限：(MEMORY_SIZE/1GB) * _max_tablet_cnt_per_gb

     • 受租户内存限制的上限：(MEMORY_SIZE * _storage_meta_memory_limit_percentage) / 200MB * 20000

   上述公式中，U 表示租户的 UNIT_NUM 数值；P 表示租户 PRIMARY_ZONE 的第一优先级个数。有关上述公式中其他参数的详细说明，请参见 查看租户和资源信息。

   根据上述计算公式，假设租户 1002 PRIMARY_ZONE 第一优先级的个数为 1， UNIT_NUM 数为 2，有广播日志流。现在需要将租户的 PRIMARY_ZONE 第一优先级个数修改为 3，则该租户所有节点上达到稳定状态的日志流个数即为 8（2*3 + 2）个。如果这些日志流发生 Transfer，则单个节点上同时存在的最大日志流个数 MAX_UNTILIZATION 可能需要达到 14（((2 * 3) *（2-1）*3)/2 + 3 + 2）个，故需要对租户进行扩容，以便能够承载 14 个日志流。

5. 计算出扩容后所需的逻辑资源后，结合节点当前逻辑资源受限的因素，确认需要调整的物理资源或配置项。

   由于租户在每个节点上能创建的逻辑资源会受到各种物理资源或配置项值的限制，可以通过视图 GV$OB_TENANT_RESOURCE_LIMIT_DETAIL 来查看租户逻辑资源具体所受的限制及各种限制的上限值。

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

   查询结果如下：

   +----------------+----------+-----------+---------------+---------------+---------------------+
   | 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
   

   从查询结果可知，租户 1002 在 172.xx.xxx.xxx:2882 节点上，限制创建的日志流个数的因素为：配置项（configuration）为 90、租户内存（memory）为 13、日志盘（clog_disk）为 32。限制创建 Tablet 个数的因素为：配置项（configuration）为 100000、租户内存（memory）为 102400 。

   根据这些上限值，可以确认需要调整的物理资源。例如，上面的示例中，如果希望单个节点最大可承载 14 个日志流，则需要调整租户内存（memory）和日志盘（CLOG_DISK）。

6. 根据扩容后所需的逻辑资源，计算扩容后单个节点所需的物理资源量。

   假设扩容后，单个节点所需的最大临时日志流个数为 14，最多需要创建的 Tablet 个数为 40000 的示例如下：

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

   计算结果如下：

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

7. 根据得到的结果，参考 通过调整资源规格实现租户扩缩容，调大租户资源规格。

租户缩容场景

对于租户缩容场景，也可以参考上述扩容场景中的方法，估算出业务运行所需的逻辑资源需求量后，再调用 DBMS_OB_LIMIT_CALCULATOR 系统包中的 CALCULATE_MIN_PHY_RES_NEEDED_BY_LOGIC_RES 子程序，计算出这些逻辑资源所需的物理资源量，最后根据业务实际情况，适当调小租户的资源规格。

此外，在通过调整 Unit Number 实现租户缩容时，如果租户有多个 Unit Group（不同 Zone 之间相同 UNIT_GROUP_ID 的 Unit 属于同一个 Unit Group），且每个 Unit Group 均比较空闲，不确定选择哪一个 Unit Group 进行删除时，可以通过以下方法来完成。

1. 使用 root 用户登录到集群的 sys 租户。

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

2. 进入 oceanbase 数据库。

   obclient> USE oceanbase;
   

3. 查看待缩容的租户所拥有的 Unit。

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

   查询结果如下：

   +---------+-----------+--------+------------------+---------------+----------------------------+----------------------------+-------+----------------+----------+---------------------+-----------------------+----------------+----------------+---------+---------+-------------+---------------+---------------------+---------------------+-------------+
   | 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
   

   根据查询结果，待缩容的租户的每个 Zone 均有 2 个 Unit。其中，UNIT_ID 为 1016、1018、1020 的 Unit 属于同一个 Unit Group，且其 UNIT_GROUP_ID 为 1006；UNIT_ID 为 1017、1019、1021 的 Unit 属于另一个 Unit Group，且其 UNIT_GROUP_ID 为 1007。

4. 执行以下命令，分别计算租户每个 Unit Group 内各 Unit 所需的最小物理资源。

   本示例中，需要分别获取 UNIT_GROUP_ID = 1006 和 UNIT_GROUP_ID = 1007 中各 Unit 所需的最小物理资源。其中，UNIT_GROUP_ID = 1006 对应的节点为 xxx.xx.xxx.194:2882、xxx.xx.xxx.192:2882、xxx.xx.xxx.204:2882；UNIT_GROUP_ID = 1007 对应的节点为 xxx.xx.xxx.198:2882、xxx.xx.xxx.196:2882、xxx.xx.xxx.197:2882。

   获取用户租户 1002 在 xxx.xx.xx.192:2882 节点上的 Unit 所需的最小物理资源的示例如下：

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

   执行结果如下：

   +----------------+----------+-----------+------------------------+------------+
   | 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
   

   参考以上方法，依次获取所有 Unit Group 内各 Unit 所需的最小物理资源后，选择资源需求量相对较少的 Unit Group 进行删除即可。

相关文档

• 查看租户和资源信息

• 通过调整资源规格实现租户扩缩容

• 通过调整 Unit Number 实现租户扩缩容

• 通过调整 Primary Zone 实现租户扩缩容