第一章 OB 分布式架构高级技术

在回收站中的对象，可以通过清空回收站的方式彻底删除，系统也会在一定的时间周期后清理回收站中的对象。Primary Zone 指的是分区的主副本所在的 Zone，可以为分区指定一个 Zone 的列表，当分区需要切主的时候，容灾策略会按照这个列表的顺序决定新主的偏好位置。OceanBase 可以把普通的表的数据按照一定的规则划分到不同的区块内，同一区块的数据物理上存储在一起。注意数据库和表组的关系，表

jonas303615108

1624人浏览 · 2025-02-20 23:51:37

jonas303615108 · 2025-02-20 23:51:37 发布

第一章主要讲 OceanBase 的资源管理和负载均衡。

1.1 相关概念

1.1.1 主可用性区 Primary Zone

Primary Zone 指的是分区的主副本所在的 Zone，可以为分区指定一个 Zone 的列表，当分区需要切主的时候，容灾策略会按照这个列表的顺序决定新主的偏好位置。
如果不设定 Primary Zone，系统会根据负载均衡的策略，在多个全功能副本里自动选择一个作为 leader。

1.1.2 数据库 Database

数据库对象，一个数据库对象中可以包含表、视图等其他数据库对象。

1.1.3 表组 Table Group

对经常会被同时访问的一组表，为了优化性能，需要将它们相同类型的副本存储在同一个 OceanBase 服务器中。通过定义一个 Table Group，并且将这一组表放在这个Table Group中来达到这个目的。此外，同一个 Table Group的多个分区表具有相同的分区数和分区规则。
Table Group 下的表，无法单独进行分区管理，需要在 Table Group 管理页面进行操作。

注意数据库和表组的关系，表组是租户下的对象，但是配置表组内的表有一个逻辑上的限制，无法配置不同数据库下的表到同一个表组。
虽然基于逻辑限制，看起来表组像是数据库的子对象，但是本质上表组是租户下的对象，并不属于某个数据库。

1.1.4 分区 Paritition

OceanBase 可以把普通的表的数据按照一定的规则划分到不同的区块内，同一区块的数据物理上存储在一起。这种划分区块的表叫做分区表。
同 Oracle 中的 Partition 概念，在 OceanBase 中只有水平分区，表的每一个分区包含一部分记录。根据行数据到分区的映射关系不同，分为 hash 分区，range 分区（按范围），list 分区等。每一个分区，还可以用不同的维度再分为若干分区，叫做二级分区。例如，交易记录表，按照用户ID 分为若干 hash 分区，每个一级 hash 分区再按照交易时间分为若干二级 range 分区。

1.1.5 副本 Repliaca

为了数据安全和提供高可用的数据服务，每个分区数据在物理上存储多份，每一份叫做分区的一个副本。每个副本，包括存储在磁盘上的静态数据（SSTable）、存储在内存的增量数据（MemTable）、以及记录事务的日志三类主要的数据。根据存储数据种类的不同，副本有几种不同的类型，以支持不同业务在在数据安全、性能伸缩性、可用性、成本等之间的选择。
● 全能型副本：也就是目前支持的普通副本，拥有事务日志，MemTable 和 SSTable 等全部完整的数据和功能。它可以随时快速切换为 Leader 对外提供服务。
● 日志型副本：只包含日志的副本，没有 MemTable 和 SSTable。它参与日志投票并对外提供日志服务，可以参与其他副本的恢复，但自己不能变为主提供数据库服务。
● 只读型副本：包含完整的日志，MemTable 和 SSTable 等，但是它的日志比较特殊。它不作为 Paxos 成员参与日志的投票，而是作为一个观察者实时追赶 Paxos 成员的日志，并在本地回放。这种副本可以在业务对读取数据的一致性要求不高的时候提供只读服务。因其不加入 Paxos 成员组，又不会造成投票成员增加导致事务提交延时的增加。

1.1.6 副本迁移 Partition migration

将分区的副本从一个节点迁到另一个节点，先在目标节点上增加一个副本，完成后再将源节点上的副本删除。

1.1.7 分区调度（Partition 负载均衡）

对于每一个租户每个 Zone 中的若干个 Unit，通过在 Unit 之间迁移副本，达到每个 Unit 内资源使用率的均衡。

属于同一个分区表的若干不同分区，会均匀分散在不同的 Unit 上，使得每个 Unit 有相同个数的分区
属于同一个 Partition Group 的若干分区，会聚集在同一个 Unit 上
在保证上述每组分区个数均衡的基础上，通过交换这组分区内的分区，降低 Server 的磁盘水位线
通过迁移非分区表的分区，降低 Server 的磁盘水位线

1.1.8 副本组 Partition Group

假设一个Table Group里的表都有N个分区，所有这些表的第i个分区的集合组成一个Partition Group。同一个Partition Group里的分区，主副本总是位于同一个Server 上。

1.1.9 回收站 Recylebin

为防止误操作，OceanBase支持回收站功能。对于表的删除，其实是将表放到一个特定的数据库下，并且对该表进行重命名。对于库的删除是为该库记录特定的删除标识。在回收站中的对象，可以通过清空回收站的方式彻底删除，系统也会在一定的时间周期后清理回收站中的对象。

1.1.10 数据大小和磁盘占用大小 Data size and required size

和分区副本数据规模相关有2个概念：“数据大小”（data_size）和“磁盘占用大小”（required_size）

一般而言，磁盘占用大小会大于数据大小，原因包括
● 数据块有最小规模，哪怕是一个字节的数据，也至少要占用一个宏块，默认为 4MB。这个类似于文件系统中小文件也会占用较大的磁盘空间
● 存储层可能维护了数据的多个版本，会导致占用空间更大

1.2 资源管理

1.2.1 物理资源占用

OceanBase 集群的每个 Server 属于一个可用区（ Zone ），可用区这个概念在分布式高可用架构里非常关键。

一个 3-3-3 集群的部署示意：

整个集群对应的资源逻辑表示：

每个 OBServer 能够使用的计算、存储资源原始还是来源于服务器的硬件资源（在不考虑使用 OFS 作为存储层的部署架构下），OBServer 进程启动的时候可以指定资源有关的参数。

参数名称	缺省值
cpu_count	主机逻辑CPU个数-2
memory_limit_percentage	80%
memory_limit	主机内存的 80%
data_disk_usage_limit_percentage	90%
datafile_size	主机数据目录空间的 90%

OBServer 启动成功后就拥有了主机的绝大部分资源。其中对内存和空间的占有是排它的，对 CPU 的占有是声明式的(因为除了主机OS，没有其他进程可以霸占CPU) 。

1.2.2 租户隔离

通常一个集群的资源较多，这些资源可能会用于支撑多个业务应用，OB通过“租户”隔离资源。其中内部租户 sys 用于集群内部运行消耗。

注意租户的资源隔离，目前只有 CPU、内存是有效限制的，磁盘空间、IOPS 是所有租户共享的。租户的资源配置是在运行时可以动态调整的，这一点对于负载可能发生变化的业务而言非常友好，扩容、缩容都很方便。

OceanBase 通过资源单元给租户分配资源，资源单元的管理基于资源规格配置和资源池，以下是一个示例：

资源单元及租户的相关要点：

资源单元(Unit)是资源分配的最小单元，同一个Unit不能跨节点(OBServer)
每个租户在一台observer上只能有一个unit
Unit是数据的容器
一个租户可以拥有若干个资源池
一个资源池只能属于一个租户
资源单元是集群负载均衡的一个基本单位

OceanBase 在决定资源单元在 OBServer 的分布时，会尽可能均衡，每个 OBServer 能够使用的资源支持通过一些参数来配置，如：

● resource_hard_limit

○ CPU和内存等资源进行分配的时候，资源总量是实际数量乘以该百分比的值，缺省为 100 表示不超卖

● resource_soft_limit

○ 当所有节点的资源水位低于该阈值时，不执行负载均衡，缺省为 50

整个系统所有 unit 的资源配置需满足，min_ 资源不大于物理资源，max_ 资源不大于超卖资源，也就是：

● sum(min_cpu) <= CPU_CAPACITY

● sum(min_memory) <= MEM_CAPACITY

● sum(max_cpu ) <= CPU_CAPACITY * resource_hard_limit

● sum(max_memory ) <= MEM_CAPACITY * resource_hard_limit

完整的负载均衡参数参见 1.3.1 章节

租户的 Unit 在不同 Zone 的分布策略则通过 Primary Zone 来配置。

1.2.3 集群资源扩容

OceanBase 集群可以在运行时动态添加 OBServer，增加集群可用资源。

反过来可以删减 OBServer 实现缩容，删除时会先把对应 OBServer 上的 unit 迁移到集群内的其它 OBServer。

以下是一个扩容示意：

扩容为：

新节点加入后，由于资源利用率很低，整个集群负载就不均衡。OceanBase 负载均衡的思路跟传统负载均衡产品不一样，OceanBase 可以靠调整自己内部 Unit 的分布来间接改变各个节点的负载。因为 Unit 内部有数据(Partition)，其中 Leader 副本集中的 Unit 就会有业务读写请求。我们可以看看发生 Resource Unit 迁移后的结果。

Resource Unit 迁移的细节是在目标节点内部先创建 Unit，然后再复制 Unit 内部的 Partition，最后做副本的角色切换(leader 跟 follower 的切换)，最后下线多余的 Partition 和 Unit。

1.2.4 租户扩容

集群资源扩容后，业务租户的 Unit 所在节点负载可能会下降一些。如果业务还是有性能问题，此时就要继续做业务租户的资源扩容。租户扩容可以通过调整 unt 规格或增加 unit_num 来实现。

返回来也可以通过调整 unit 规格或减少 unit_num 来实现缩容

租户资源的扩容/缩容是通过调整其 Resource Unit 的规格和数量来完成。

比如说从规格S2升级到S3：

● alter resource pool pool_mysql unit='S3';

或者不调整规格，而是增加Unit的数量：

● alter resource pool pool_mysql unit_num=2;

租户扩容增加 unit 数量示意：

扩容为：

当扩容后，部分Partition的位置发生变化，同时leader副本也出现在其他Zone里。

注意，在这个Partition迁移过程中，还有个特点就是同一个分区组内的Partition最终会迁移到同一个Unit内部。迁移期间有短暂时间可能出现分布在两个Unit里，可能导致有跨节点查询或者分布式事务，性能会短暂下跌一些然后很快恢复，这个是业务需要承受的。一般业务压力不大的时候感知不到数据库性能这细小的变化。

1.2.5 回收站管理

为防止误操作，OceanBase支持回收站功能。

回收站的实现原理

● 表移到隐藏的 __recyclebin Database ，并且对该表进行重命名

● database 通过重命名和标记为 in_recyclebin=true 实现

在回收站中的对象，可以通过清空回收站的方式彻底删除，系统也会在一定的时间周期后清理回收站中的对象。

回收站使用参考的官方文档： https://www.oceanbase.com/docs/oceanbase-database/oceanbase-database/V2.2.50/objects-supported-by-recycle-bin

1.2.5.1 回收站相关配置

提供3个和回收站相关的租户变量配置

● 是否启用回收站功能： set recyclebin = on / off;

● 是否支持 truncate table： set ob_enable_truncate_table = on /off;

● 是否支持 truncate table 闪回：set ob_enable_truncate_flashback= on /off;

提供1个和回收站相关的集群参数配置

• 回收站保留时间： alter system set recyclebin_object_expire_time='7d';

注意回收站未启用时， “Truncate进入回收站”、“回收站保留时间” 配置值不生效

-- tenant level recyclebin settings
set GLOBAL recyclebin = on / off;
set GLOBAL ob_enable_truncate_table = on /off;
set GLOBAL ob_enable_truncate_flashback = on /off;

-- session level recyclebin settings
set @@recyclebin = on / off;
set @@ob_enable_truncate_table = on / off;
set @@ob_enable_truncate_flashback = on / off;

-- recyclebin object expire time, cluster level parameter, 
-- can only be set in sys tenant
-- default 0 that means auto purge recyclebin off. Range: [0s, +∞)                                     | ROOT_SERVICE   | CLUSTER | DEFAULT | DYNAMIC_EFFECTIVE |
alter system set recyclebin_object_expire_time='7d';

查询当前配置值 SHOW GLOBAL VARIABLES

show variables like 'recyclebin';
show variables like 'ob_enable_truncate_flashback';

回收站保留时间则通过租户内系统参数查看（ parameters, not variables）

show parameters like 'recyclebin_object_expire_time';

其他相关参数

-- the hour of expire time for schema history, 
-- from 1hour to 30days, with default 7days. Range: [1h, 30d]                
show parameters like 'schema_history_expire_time';

1.2.5.2 查看回收站内对象

-- oceanbase/oracle style
SHOW RECYCLEBIN;

-- use mysql INFORMATION_SCHEMA
SELECT * FROM INFORMATION_SCHEMA.USER_RECYCLEBIN;

1.2.5.3 恢复（闪回 FLASHBACK）

-- recover table, support recover table into identified database
FLASHBACK TABLE object_name TO BEFORE DROP [RENAME TO db_name.table_name];

-- recover database
FLASHBACK DATABASE object_name TO BEFORE DROP [RENAME TO db_name];

1.2.5.4 清空 PURGE

-- 用于从回收站把指定库物理删除
PURGE DATABASE <object_name>;

-- 用于从回收站中把指定表真正物理删除
PURGE TABLE <object_name>;

-- 指定索引表物理删除
PURGE INDEX <object_name>;

-- 用于清空整个回收站
PURGE RECYCLEBIN;

1.3 负载均衡

1.3.1 负载均衡参数详解

可通过以下语句查找负载均衡相关的系统参数

SELECT `name`, scope, info FROM __all_virtual_sys_parameter_stat
    WHERE section='LOAD_BALANCE';

负载均衡开关

● enable_rebalance 自动负载均衡开关

● enable_rereplication 自动补副本开关

负载均衡阈值

● resource_soft_limit 当所有节点的资源水位低于该阈值时，不执行负载均衡

● resource_hard_limit CPU和内存等资源进行分配的时候，资源总量是实际数量乘以该百分比的值

● balancer_tolerance_percentage 负载均衡策略中，决定均衡水位线上下可容忍的范围（百分比）

● balancer_emergency_percentage 当Unit负载超过该阈值时，即使在合并期间也执行负载均衡

负载均衡权重

● enable_unit_balance_resource_weight 负载均衡的时候，是否允许配置的资源权重生效

● unit_balance_resource_weight Unit均衡策略中使用的资源权重，一般不需要手工配置。

○ 当打开 enable_unit_balance_resource_weight 时本配置才生效。

● server_balance_critical_disk_waterlevel 磁盘水位线超过该阈值时，负载均衡策略将倾向于优先考虑磁盘均衡

● server_balance_disk_tolerance_percent 节点间负载均衡策略中，磁盘不均衡程度的容忍度

● server_balance_cpu_mem_tolerance_percent 节点负载均衡策略中，CPU和内存资源不均衡的容忍度

负载均衡租户策略

● enable_sys_unit_standalone 系统租户Unit是否独占节点

● tenant_Groups 设置负载均衡策略中使用的租户组，详见负载均衡文档说明

● resource_exclusive_tenant 设置时，将开启某个租户独占资源的节点负载均衡策略，用于磁盘异构的集群。详见负载均衡文档

负载均衡并发度

● data_copy_concurrency 系统中并发执行的数据迁移复制任务的最大并发数

● server_data_copy_out_concurrency 单个节点迁出数据最大并发数

● server_data_copy_in_concurrency 单个节点迁入数据最大并发数

无论是自动负载均衡还是手动负载均衡，所有的 Unit 迁移和 Partition 迁移的事件都可以在 RS 服务的事件日志表__all_rootservice_event_history 里查询。

参数设置场景举例

● 在特殊的时期，比如说类似双11大促，为了防止负载均衡导致数据库性能抖动引起业务的雪崩，配置关闭自动负载均衡，alter system set enable_rebalance='FALSE';

1.3.2 设置 PrimaryZone 减少跨机房请求

Primary Zone 表示 Leader 副本的偏好位置，指定 Primary Zone 实际上是指定了 Leader 更趋向于被调度到哪个Zone 上。

【例】某张表 t1 的 Primary_Zone="Zone1"，则 RS 会尽量将 t1 表的 Leader 调度到 Zone1 。

当Primary Zone列表包含多个Zone时，用;分隔的具有从高到底的优先级；用,分隔的具有相同优先级。

【例】 hz1,hz2;sh1,sh2;sz1 表示

● hz1 和 hz2 具有相同的优先级，并且优先级高于 sh1，sh2 和 sz1；

● sh1 和 sh2 具有相同优先级，并且优先级高于 sz1。

注意：如果最高优先级只配置1个 Zone，那么 Leader 副本只会在一个 Zone，leader 将不均衡，一般不推荐这么做。

Primary Zone 的设置隐含的包含了 Leader 偏好的 region 位置，也就是说用户设置 Primary_Zone 包含两层语义：

● 被指定的 Primary Zone 为 Leader 的偏好 Zone 的位置；

● 被指定 Primary Zone 所在的 region 为 Leader 偏好的 region。

具体地，leader 会被优先调度到最高优先级的 Zone 上去，如果最高优先级的 Zone 上的副本不能成为leader，会优先选择同一个 region 内的其他 Zone 作为 Leader 的位置。

1.3.3 使用 TableGroup 减少跨节点请求和分布式事务

在默认配置下，所有 Leader 会被打散到 Primary Zone 的 OBServer 中，这带来分布式事务的问题，比如多表 join 的查询场景，如果不同表的 Leader 分布在不同的 OBServer 中，那么事务就需要跨多个 OBServer，产生分布式事务。分布式事务比本地事务/跨机事务消耗更多资源，应尽量避免。

1.3.2 描述的 Primary Zone 不仅可以配置到租户，也可以可以设置到 Table/Table Group/Database，并且有继承关系，继承关系在不同版本创建的 Table Group 中有差异：

● 在 2.x 创建的 Table Group 中，继承关系：Table <-- Table Group <-- Tenant；

● 在 1.x 创建的 Table Group 中，继承关系：Table <-- Database <-- Tenant。

其实目前 Table Group 不能跨 Database ，所以用户角度这两种继承关系也没什么差别。

相同 TableGroup 下的表，具有相同的分区策略、分区数量、leader 分布。如果配置了 TableGroup， Table 就不能设置单独的 Primary Zone 了。从而实现 TableGroup 下的多表事务可以减少跨机（前提是关联字段包含分区键）。