首批通过分布式安全可靠测评,为关键业务系统打造
租户内均衡
更新时间:2026-05-25 17:18:25
在 OceanBase 数据库 V3.x 版本中,副本以分区为粒度分布在多节点上,负载均衡模块可以通过分区切主、迁移分区副本等方式实现租户内分区均衡。V4.x 版本中升级为单机日志流架构后,副本以日志流为粒度分布,每个日志流上承载着大量分区。因此,在 V4.2.x 版本中,负载均衡模块无法直接控制分区分布,而是需要先对 LS(Log Stream,日志流)的数量和 Leader 进行均衡,然后才能在日志流分布的基础上再进行分区均衡。
注意
分区均衡仅针对用户表。
LS 均衡与分区均衡的优先级顺序如下:
LS 均衡 > 分区均衡
LS 均衡
LS 数量均衡
当用户对租户执行 UNIT_NUM 变更、修改 PRIMARY_ZONE 的第一优先级、修改 Locality(影响 PRIMARY_ZONE)等操作时,负载均衡模块的后台线程会立即通过 LS 分裂、LS 合并、LS Group 变更等动作,变更 LS 的数量和位置,以满足用户修改后的租户状态,即每个租户的 Unit 都有一个日志流组,日志流组内日志流的个数等于 PRIMARY_ZONE 的第一优先级的个数,Leader 在日志流组内均衡地分布在各个 Zone 上。
说明
- LS Group 是 LS 的属性,LS Group ID 相同的日志流会聚合在一起。
- 从 V4.0.0 版本开始,OceanBase 数据库要求租户内每个 Zone 的 Unit 个数必须保持一致。为了方便统一管理各个 Zone 的 Unit,系统引入了 Unit Group 机制,即不同 Zone 之间相同编号(UNIT_GROUP_ID)的 Unit 属于同一个 Unit Group。Unit Group 内所有 Unit 上的数据分布相同,具有相同的日志流副本,服务相同的分区数据。从资源容器上,Unit Group 框定了一组数据,这组数据由一个或多个日志流服务,读写服务能力可以扩展到 Unit Group 内的多个 Unit 上。
- 一个 LS Group 唯一对应一个 Unit Group,也就是相同 LS Group ID 的日志流分布于相同的 Unit Group 内。
LS 数量的计算公式如下:
LS 数量 = UNIT_NUM * first_level_primary_zone_num
说明
此处 LS 数量指的是用户日志流的数量,不包含系统日志流和广播日志流。
LS 数量均衡的场景如下表所示。
| 触发均衡的场景示例 | 均衡条件 | 均衡算法 | LS 均衡策略 |
|---|---|---|---|
PRIMARY_ZONE:从 z1, z2 变更为 z1同时 UNIT_NUM :从 1 变更为 2 |
LS Group 中有的缺少 LS 和有的有多余 LS,但 LS 的总数量符合终态 | 迁移冗余 LS 至缺少 LS 的 LS Group 中 | LS_BALANCE_BY_MIGRATE |
PRIMARY_ZONE: 从 z1 变更为 z1,z2 或者 UNIT_NUM:从 2 变更为 3 |
仅存在 LS Group 缺少 LS | 假设当前 LS 的个数为 M,扩容后 LS 的个数为 N(M < N),则每个缺少的 LS 都需要得到 M/N 个 Tablet |
LS_BALANCE_BY_EXPAND |
PRIMARY_ZONE: 从 z1,z2 变更为 z1 或者 UNIT_NUM:从 3 变更为 2 |
仅存在 LS Group 有多余 LS | 假设当前 LS 的个数为 M,需要缩容到 N 个 LS 上(M > N),则剩下的每个 LS 都需要分到 (M-N)/N 个 Tablet |
LS_BALANCE_BY_SHRINK |
示例 1:如下图所示,PRIMARY_ZONE 的第一优先级从 Z1, Z2 变更为 Z1;同时 UNIT_NUM 需要从 1 变更为 2。变更前后,LS 数量不变,直接将 LS2迁移到新建的 Unit 上,LS2 根据 PRIMARY_ZONE 的变更切主到 Z1,最终完成 LS 均衡。

示例 2:如下图所示,PRIMARY_ZONE = Z1,UNIT_NUM 从 1 变更为 2,为保证每个 Unit 都有 LS,分裂出 LS2,带走 1/2 的 Tablet,迁移到新的 Unit 上。

示例 3:如下图所示,UNIT_NUM = 1,PRIMARY_ZONE 的第一优先级从 RANDOM 变更为 Z1,Z2。为保证 Leader 仅在 PRIMARY_ZONE 第一优先级的 Zone 上,还需要保证均衡完后,日志流上的 Tablet 的数量均衡。由于 LS3 与其余 LS 在同一个 LS Group 中,可以直接从 LS3 上 Transfer 走 1/2 的 Tablet 到 LS1 上,然后再将 LS3 合并到 LS2 上,让 LS2 承载剩余 1/2 的 Tablet,就可以在减少 LS 数量的同时保持 Tablet 数量均衡。

LS Leader 均衡
LS Leader 均衡是在 LS 数量均衡的前提下,让 LS Leader 平均分布在 Primary Zone 上。例如,用户变更租户的 PRIMARY_ZONE 后,负载均衡后台线程会根据 PRIMARY_ZONE 的第一优先级动态调整 LS 数量,之后再对 LS 进行切主,保证第一优先级的各 Zone 内均有且仅有一个 LS Leader。
例 1:如下图所示,UNIT_NUM = 1,PRIMARY_ZONE 的第一优先级从 Z1 变更为 Z1,Z2,为保证 PRIMARY_ZONE 第一优先级的所有 Zone 上都有 Leader,在同一个 Unit 里分裂出新的 LS,然后再通过 LS Leader 均衡将新 LS 的 Leader 切到 Z2。

例 2:如下图所示,当 UNIT_NUM = 1,PRIMARY_ZONE 的第一优先级从 RANDOM 变更为 Z1,Z2时,经过 LS 数量均衡将 LS3 合并入其他 LS 后,剩余的 LS Leader 天然平均分布在Z1 和 Z2 上,无需额外的 LS Leader 均衡。

建表时分区的分配
当用户创建用户表时,OceanBase 数据库会采用一套均衡分配策略将分区打散或聚合到各个用户日志流上,以保证各个日志流上分区的相对均衡。
指定 Table Group 的用户表
用户可以通过指定 Table Group,灵活配置不同表之间的聚集、打散规则。在创建用户表时,如果指定了对应 Sharding 属性的 Table Group,则新建用户表的分区会按照 Table Group 的规则分配到对应用户的 LS 上。Table Group 的规则如下表所示。
| Table Group 的 Sharding 属性 | 说明 | 分区方式要求 | 对齐规则 |
|---|---|---|---|
| NONE | 所有表的所有分区都聚集在同一台 Server | 无限制 | 所有分区与表组中 table_id 最小的表的分区聚集在同一个 LS |
| PARTITION | 按一级分区打散。如果是二级分区表,则一级分区下的所有二级分区聚集在一起 | 要求所有表的一级分区的分区方式相同;如果是二级分区表,也只校验一级分区的分区方式。因此,一级分区表和二级分区表可以同时存在,只要他们的一级分区的分区方式相同即可。 | 相同一级分区 Value 的分区聚集在一起,包括:一级分区表的一级分区和二级分区表的对应一级分区下的所有二级分区。 |
| ADAPTIVE | 自适应打散方式。如果 Table Group 内是一级分区表,则按一级分区打散;如果Table Group 内是二级分区表,则按每个一级分区下的二级分区打散。 |
|
|
注意
如果在建表前,Table Group 中已存在用户表,后续新建的表会按 Table Group 中 table_id 最小的用户表对应的分区分布对齐。
有关 Table Group 的更多介绍,请参见 关于表组。
普通用户表
不指定 Table Group 创建普通用户表时,OceanBase 数据库默认将新建分区打散到所有用户 LS 上。具体规则如下。
非分区表:新建分区分配到分区数最少的用户 LS 上。
一级分区表:一级分区表:一级分区按照 Round Robin 算法,平均分布到所有用户 LS 上。
二级分区表:二级分区表:每个一级分区下所有二级分区按照 Round Robin 算法,平均分布到所有用户 LS 上。
下面通过几个示例来进行说明。
示例 1:在 MySQL 模式下分别创建了
tt1、tt2、tt3、tt4等 4 张非分区表。obclient [test]> CREATE TABLE tt1(c1 int);obclient [test]> CREATE TABLE tt2(c1 int);obclient [test]> CREATE TABLE tt3(c1 int);obclient [test]> CREATE TABLE tt4(c1 int);查询 4 张表的分区分布情况。
obclient [test]> SELECT table_name,partition_name,subpartition_name,ls_id,zone FROM oceanbase.DBA_OB_TABLE_LOCATIONS WHERE table_name in('tt1','tt2','tt3','tt4') AND role='LEADER';查询结果如下。
+------------+----------------+-------------------+-------+------+ | table_name | partition_name | subpartition_name | ls_id | zone | +------------+----------------+-------------------+-------+------+ | tt1 | NULL | NULL | 1001 | z1 | | tt2 | NULL | NULL | 1002 | z2 | | tt3 | NULL | NULL | 1003 | z3 | | tt4 | NULL | NULL | 1001 | z1 | +------------+----------------+-------------------+-------+------+ 4 rows in set示例 2:再创建一个一级分区表
tt5。obclient [test]> CREATE TABLE tt5(c1 int) PARTITION BY HASH(c1) PARTITIONS 6;查看该分区表的分布情况。
obclient [test]> SELECT table_name,partition_name,subpartition_name,ls_id,zone FROM oceanbase.DBA_OB_TABLE_LOCATIONS WHERE table_name ='tt5' AND role='LEADER';查询结果如下。该表的一级分区按照 Round Robin 算法平均分布到了
1001、1002、1003等日志流上。+------------+----------------+-------------------+-------+------+ | table_name | partition_name | subpartition_name | ls_id | zone | +------------+----------------+-------------------+-------+------+ | tt5 | p0 | NULL | 1003 | z3 | | tt5 | p1 | NULL | 1001 | z1 | | tt5 | p2 | NULL | 1002 | z2 | | tt5 | p3 | NULL | 1003 | z3 | | tt5 | p4 | NULL | 1001 | z1 | | tt5 | p5 | NULL | 1002 | z2 | +------------+----------------+-------------------+-------+------+ 6 rows in set示例 3:创建一个二级分区表
tt8。obclient [test]> CREATE TABLE tt8 (c1 int, c2 int, PRIMARY KEY(c1, c2)) PARTITION BY HASH(c1) SUBPARTITION BY RANGE(c2) SUBPARTITION TEMPLATE (SUBPARTITION p0 VALUES LESS THAN (1990), SUBPARTITION p1 VALUES LESS THAN (2000), SUBPARTITION p2 VALUES LESS THAN (3000), SUBPARTITION p3 VALUES LESS THAN (4000), SUBPARTITION p4 VALUES LESS THAN (5000), SUBPARTITION p5 VALUES LESS THAN (MAXVALUE)) PARTITIONS 2;查看表
tt8的分区分布情况。obclient [test]> SELECT table_name,partition_name,subpartition_name,ls_id,zone FROM oceanbase.DBA_OB_TABLE_LOCATIONS WHERE table_name ='tt8' AND role='LEADER';查询结果如下。该表下一级分区的所有二级分区按照 Round Robin 算法,平均分布到了用户的所有 LS 上。
+------------+----------------+-------------------+-------+------+ | table_name | partition_name | subpartition_name | ls_id | zone | +------------+----------------+-------------------+-------+------+ | tt8 | p0 | p0sp0 | 1001 | z1 | | tt8 | p0 | p0sp1 | 1002 | z2 | | tt8 | p0 | p0sp2 | 1003 | z3 | | tt8 | p0 | p0sp3 | 1001 | z1 | | tt8 | p0 | p0sp4 | 1002 | z2 | | tt8 | p0 | p0sp5 | 1003 | z3 | | tt8 | p1 | p1sp0 | 1002 | z2 | | tt8 | p1 | p1sp1 | 1003 | z3 | | tt8 | p1 | p1sp2 | 1001 | z1 | | tt8 | p1 | p1sp3 | 1002 | z2 | | tt8 | p1 | p1sp4 | 1003 | z3 | | tt8 | p1 | p1sp5 | 1001 | z1 | +------------+----------------+-------------------+-------+------+ 12 rows in set
特殊用户表
除了普通用户表外,有局部索引表、全局索引表、复制表这些特殊用户表,具有特别的分配规则。具体如下:
局部索引表:与用户表主表的分区规则相同,每个分区与主表的分区分布绑定在一起。
全局索引表:默认为非分区表,建表时分布到分区数量最少的用户 LS 上。
复制表:复制表仅存在于广播日志流上。
分区均衡
在 LS 均衡的基础上,负载均衡模块会通过 Transfer,将分区 Tablet 打散或聚合在不同的 LS 上,达到租户下的分区均衡。分区均衡任务 SCHEDULED_TRIGGER_PARTITION_BALANCE 由 DBMS_BALANCE.TRIGGER_PARTITION_BALANCE 子程序控制,默认每天的 00:00 触发一次分区均衡。有关分区均衡相关的操作,参见 配置定时分区均衡任务。
分区均衡策略的优先级顺序如下:
分区属性对齐 > 表组和分区权重均衡 > 分区数量均衡 > 分区磁盘均衡
分区属性对齐
Table Group 对齐
当用户通过 SQL 语句修改表的 Table Group 属性或 Table Group 的 Sharding 属性时,需要等待后台的分区均衡任务执行完成,才能达到符合预期的分区分布。可以通过手动调用 DBMS_BALANCE.TRIGGER_PARTITION_BALANCE 子程序来触发一次分区均衡以便快速对齐。
Table Group 中表的分区分布规则请参见本文 指定 Table Group 的用户表 中的内容。
有关 Table Group 的更多介绍,请参见 关于表组。
duplicate_scope 对齐
在 OceanBase 数据库当前版本中,支持复制表属性的变更。复制表只能存在于广播日志流上。当用户修改 duplicate_scope 属性后,需要等待分区均衡执行完成后才能按照预期属性使用。可以通过手动调用 DBMS_BALANCE.TRIGGER_PARTITION_BALANCE 子程序来触发一次分区均衡以便快速对齐。
有关复制表属性变更的详细操作,参见 更改复制表属性(MySQL 模式) 和 更改复制表属性(Oracle 模式)。
表组权重均衡
OceanBase 数据库的 MySQL 模式通过将 Database 绑定到一个 Sharding = 'NONE' 的表组上来实现用户表的聚合。当前支持同一个 Database 下的用户表的自动聚合和多个 Database 下的用户表聚合。
通过为 Sharding = 'NONE' 的表组设置权重实现表组权重均衡,可以帮助自动聚合的 Database 下的用户表按权重分布。表组权重均衡是分区均衡(PARTITION_BALANCE)任务中的一个过程,用户租户可以通过手动触发,或者等待定时分区均衡任务触发。
分区权重均衡(非表组)
分区权重是用户设置的分区之间占用 CPU、内存、磁盘等资源的相对比重。仅支持整数值,取值范围为 [1, +∞)。默认情况下,分区没有权重。
非表组分区权重均衡是分区均衡任务中的一个过程,用户为表设置分区权重后,可以通过手动触发分区均衡任务来实现,也可以等待定时分区均衡任务触发来实现。分区权重均衡算法是通过分区移动和分区交换的方法,使各个用户日志流上分区权重之和的方差尽量小。
只有设置过分区权重的表才会参与分区权重均衡,对于表中未设置分区权重的分区,将仍然按照分区个数进行均衡。
分区权重均衡的应用
非表组的分区权重主要应用于分区热点打散,主要支持以下两个场景:
一级分区表表内热点分区打散
非分区表表间分区热点打散
说明
- 当前暂不支持二级分区表的表内均衡。
- 非分区表与分区表混合的场景属于表间权重均衡。
在设置分区权重时,建议最多划分三挡:
大权重 = 100% * 分区数
中权重 = 50% * 分区数
小权重 = 1
下面通过几个应用场景的示例,介绍分区权重均衡的应用。
一级分区表表内热点分区打散
例如,假设有一个一级分区表 t1,表上共有 6 个分区,建表后,其分区分布如下所示。

有以下应用场景:
应用场景一:少量热点打散
假设一级分区表 t1 中只有 p0、p3 两个分区为热点分区,需要打散。以权重档位最少为原则,可以仅使用一个权重档位,即 “小权重 = 1” 来解决。
设置分区权重
p0 = 1、p3 = 1。在进行分区均衡计算时,仅对这两个分区进行权重均衡,剩余分区不参与权重均衡,仍按照分区数量均衡,尽量不动。经过分区均衡(手动触发或者等待定时均衡触发)后,总体分区分布如下所示。
应用场景二:所有分区按权重分布
假设一级分区表 t1 中 p0 的流量最大,p1、p2、p3 次之,其余分区流量较少。如果想要流量打散,可以使用以下三档权重:
大权重 = 100% * 一级分区表的分区数 = 6
中权重 = 50% * 一级分区表的分区数 = 3
小权重 = 1
先设置表级分区权重为 1,划分权重分区均衡的范围为整张分区表,然后单独设置分区权重
p0 = 6、p1 = 3、p2 = 3、p3 = 3。经过分区均衡后,总体分区分布如下所示。
应用场景三:热点分区均衡组内独占
假设一级分区表 t1 中,6 个分区的流量极度不均衡,存在两个超大分区 p0 和 p3,现在期望表内其他分区不要影响这两个超大分区的读写。可以使用以下两档权重:
大权重 = 100% * 一级分区表的分区数 = 6
小权重 = 1
先设置表级分区权重为 1,划分权重分区均衡的范围为整张分区表,然后单独设置分区权重
p0 = 6、p3 = 6。经过分区均衡后,总体分区分布如下所示。
非分区表热点打散
例如,假设有以下 6 张非分区表,创建表后,其分布如下所示。

有以下应用场景:
应用场景一:少量热点打散
假设非分区表 non_part_t1 和 non_part_t4 为同一个日志流上的两个热点,需要打散。以权重档位最少为原则,可以只使用一个权重档位 “小权重 = 1” 来解决。
设置非分区表的表级权重
non_part_t1 = 1、non_part_t4 = 1。经过分区均衡后,分布如下所示。
应用场景二:按流量分布
假设已知各个非分区表的流量,non_part_t1 最大,non_part_t2、non_part_t3 次之,non_part_t4、non_part_t5、non_part_t6 最小,期望按流量打散。可以使用以下三档流量:
大权重 = 100% * 一级分区表的分区数 = 6
中权重 = 50% * 一级分区表的分区数 = 3
小权重 = 1
设置对应表的表级分区权重
non_part_t1 = 6、non_part_t2 = 3,non_part_t3 = 3,non_part_t4 = 1,non_part_t5 = 1,non_part_t6 = 1后,经过分区均衡后,分布如下所示。
分区权重对表组的影响
带有分区权重的表可以被加入到表组。对于表组而言,如果表组中存在带分区权重的表,分区均衡会根据分区组内加权总和计算分布。带分区权重表加入表组后对表组的具体影响如下表所示。
| 表组的 SHARDING 属性 | 原来的分区分布方式 | 带分区权重后的影响 |
|---|---|---|
| NONE | 全部聚合 | 无影响 |
| PARTITION | 各表的一级分区内 Value 相同的分区聚合(同一分区组);一级分区之间打散。 | 少数带权重的分区会影响表组的整体分布。 |
| ADAPTIVE |
|
表组内全部是一级分区表时,少数带权重的分区会影响表组的整体分布。目前暂不支持对二级分区表设置分区权重。 |
下面以一个简单的示例说明,表组中某个表的分区被设置分区权重后,对表组整体分布的影响。
假设,当前有一个表组,其 SHARDING = PARTITION,表组中有 t1、t2 两张一级分区表,且每张表中各有 6 个分区,各表的一级分区绑定为一个分区组,原始分区分布如下所示。

将一级分区表 t1 的所有分区的权重先设置为 1,再设置 t1_p0=6、t1_p1=6,分区均衡后,表组内的分区分布如下所示。

分区数量均衡
分区数量均衡的目标是让所有用户的 LS 上的用户表主表分区数量均匀(数量偏差不大于 1)。
实现上,OceanBase 数据库采用 “均衡组” 的概念描述打散关系,将需要打散分布的分区划分到同一个均衡组内,通过组内均衡和组间均衡的方式实现分区数量均衡。
无 Table Group 的场景下,均衡组的划分方式如下:
| 表类型 | 均衡组划分 | 分布方式(无 Table Group) |
|---|---|---|
| 非分区表 | 租户下所有非分区表是一个均衡组。 | 租户下所有非分区表,平均分布到用户的所有 LS 上(数量偏差不大于 1)。 |
| 一级分区表 | 每张表下所有一级分区是一个均衡组。 | 以每张表为单位,一级分区平均分布到用户的所有 LS 上。 |
| 二级分区表 | 单张表的每个一级分区下的所有二级分区是一个均衡组。 | 单张表每个一级分区下的所有二级分区,平均分布到用户的所有 LS 上。 |
均衡阶段,系统先对所有均衡组进行组内均衡,即组内分区平均分布,然后再在组内均衡的基础上,从分区数最多的 LS 上 Transfer 走一部分分区,进行组间均衡,从而实现分区数量均衡。
例如,现有 4 张表的所有分区均在 LS1 上,分为 3 个均衡组:
均衡组 1:非分区表
non_part_t1、non_part_t2均衡组 2:一级分区表的 2 个分区
part_one_t3_p0、part_one_t3_p1均衡组 3:二级分区表的 4 个分区
part_two_t4_p0s0、part_two_t4_p0s1、part_two_t4_p1s0、part_two_t4_p1s1
初始分布,各分区分布为 8-0-0。

组内均衡后,各分区分布为 4-4-0,各均衡组已达到均衡,但总体未均衡。

组间均衡后,分区分布为 3-3-2 ,从分区最多的 LS1 、LS2 上各 Transfer 走一个分区到分区数最少的 LS3 上,总体达到均衡。

当存在 Table Group 时,每个 Table Group 是一个独立均衡组,系统会将 Table Group 要求聚集的分区进行绑定,视为一个分区。然后采用同样的组内均衡、组间均衡方式进行分区数量均衡。存在 Table Group 时,租户下所有分区数量可能无法达到完全平均。
存在 Table Group 的场景下,均衡组的划分方式如下:
| 表类型 | 均衡组划分 | 分布方式 |
|---|---|---|
Table Group 的 Sharding 属性为 NONE 的表 |
自成一个均衡组 | Table Group 下所有分区都分布在一个日志流上 |
Table Group 的 Sharding 属性为 PARTITION 或 ADAPTIVE 的一级分区表 |
所有表的一级分区是一个均衡组 | 第一张表平均分区到所有的日志流上,后面的表的位置均与第一张表聚集 |
Table Group 的 Sharding 属性为 ADAPTIVE 的二级分区表 |
所有表一级分区下的所有二级分区是一个均衡组 | 第一张表每个一级分区下的所有二级分区平均打散在所有日志流上,后面的表的位置均与第一张表聚集 |
例如,在上面均衡后的基础上,再新增一个 sharding = 'NONE' 的 Table Group tg1,其中包含 non_part_t5_in_tg1、non_part_t6_in_tg1、non_part_t7_in_tg1、non_part_t8_in_tg1、non_part_t9_in_tg1等五个非分区表。由于 tg1 中的所有表必须绑定到一起,均衡后表的分区分布为 4-4-5。

分区磁盘均衡
在分区数量或分区权重均衡的基础上,负载均衡模块通过尽可能地交换分区,实现各个日志流之间的磁盘占用差值不超过集群级配置项 balancer_tolerance_percentage 所设置的百分比。如果单分区磁盘占用过大,可能会达不到该均衡效果。
为避免小数据量场景均衡过于频繁的问题,当前版本分区磁盘均衡触发的阈值为 "50GB",若单个 LS 磁盘占用小于该阈值,则不会触发磁盘均衡。
分区均衡的判断方法
分区均衡是用户表主表的均衡,查询时需要指定 table_type='USER TABLE'。分区磁盘均衡主要通过视图 CDB_OB_TABLET_REPLICAS 中的 data_size 字段来判断。
分区数量均衡的查询方法
obclient [test]> SELECT svr_ip,svr_port,ls_id,count(*) FROM oceanbase.CDB_OB_TABLE_LOCATIONS WHERE tenant_id=xxx AND role='leader' AND table_type='USER TABLE' GROUP BY svr_ip,svr_port,ls_id;分区磁盘均衡的查询方法
obclient [test]> SELECT a.svr_ip,a.svr_port,b.ls_id,sum(data_size)/1024/1024/1024 as total_data_size FROM oceanbase.CDB_OB_TABLET_REPLICAS a, oceanbase.CDB_OB_TABLE_LOCATIONS b WHERE a.tenant_id=b.tenant_id AND a.svr_ip=b.svr_ip AND a.svr_port=b.svr_port AND a.tablet_id=b.tablet_id AND b.role='leader' AND b.table_type='USER TABLE' AND a.tenant_id=xxxx GROUP BY svr_ip,svr_port,ls_id;
分区聚合后再打散场景
分区均衡是动态维持系统负载平衡的一个持续性过程。在业务的实际运行中,系统会根据实时负载状态进行分区的聚合与再打散,实现资源利用效率与性能的最优平衡。常见的分区聚合后再打散的场景如下:
租户进行水平缩容后再扩容。例如,将租户的
UNIT_NUM个数从 N -> 1,再从 1 -> N。租户的
PRIMARY_ZONE第一优先级个数先较少后再增多。例如,将租户的PRIMARY_ZONE从RANDOM->zone1,再从zone1->RANDOM。将大量表加入到 Sharding 属性为
NONE的表组后,再将表从表组中移除。
根据现有的日志流均衡和分区均衡算法,在分区聚合再打散后,会出现分区表内连续的分区聚在同一条日志流上,或者同一 Database 下的非分区表聚集到同一日志流上的情况。为了解决该问题,OceanBase 数据库对分区均衡算法进行了优化:
针对非分区表,在分区聚合再打散后,同一个 Database 下的多个非分区表,会在各个用户日志流上打散分布,按照分区数量均衡;避免了同一个 Database 下的非分区表在同一个日志流上连续。
针对分区表,在分区聚合再打散后,同一个分区表的连续分区,会按照 Round Robin 方式在各个用户日志流上打散分布,按照数量均衡;避免了分区表的分区在同一个日志流上连续。