首批通过分布式安全可靠测评,为关键业务系统打造
部署与使用列存副本
更新时间:2026-06-17 13:19:58
为支持 TP 与 AP 混合负载等场景,OceanBase 数据库支持列存副本(COLUMNSTORE,简称 C 副本)。C 副本可部署在独立 Zone 上;用户表(含复制表,不含索引表、内部表、系统表)在该副本中以列存格式存储。
本篇文档将介绍 C 副本在租户 Locality 中完成部署的步骤,并介绍如何 使用 C 副本。
使用限制与注意事项
使用限制
- C 副本与 F 或 R 副本 不支持 互相转换。
- 物理恢复 不支持恢复 C 副本;租户的 Locality 若包含 C 副本,恢复将失败。
部署建议
- 从 V4.3.5 BP1 起支持部署多个 C 副本,建议最多 3 个。
- OceanBase V4.6.0 版本以前,建议 C 副本所在 Zone 只部署 C 副本;该独立 ODP 需 ODP V4.3.2 及以上。
- 主库未部署 C 副本时,备库不建议 部署 C 副本。
运维注意事项
- 在部署 C 副本的集群中执行 DDL 操作时,系统资源消耗通常会有所增加。其主要原因是系统在处理行存数据的同时,还需要额外处理列存数据,且提交日志(clog)也需同步写入对应副本,因此会对 CPU、内存、磁盘和 I/O 等资源带来更高压力。
- C 副本 合并 通常慢于 F/R;上一轮合并未完成时,无法发起新一轮租户级合并。手动合并前建议查看 CDB_OB_ZONE_MAJOR_COMPACTION、DBA_OB_ZONE_MAJOR_COMPACTION,详见 查看合并信息。
部署列存副本
在租户 Locality 中指定 C 副本即可,常见两类操作:
- 场景 A:新建租户时即包含 C 副本。
- 场景 B:为已有租户增加 C 副本(新 Zone + 调整 Locality)。
以下 SQL 示例中的 CPU、内存、磁盘等数值仅为示例参考,请按实际负载与资源规划调整。
场景 A:新建包含 C 副本的租户
假设当前有一个已部署好的集群,且集群的部署模式为 2F1A(两副本+ 1 个仲裁服务)。集群中的 3 个 Zone 分别为 zone1、zone2、zone3,仲裁服务部署在 zone3 上。需要在该集群上创建一个含有 C 副本的租户,步骤如下:
找到一台能够与当前集群网络互通的机器,并在该机器上部署 ODP。
为防止资源争抢,建议 ODP 单独部署在一台机器上。部署 ODP 时,要求其版本必须为 ODP V4.3.2 及以上版本。有关部署 ODP 的详细操作,参见 部署 ODP。
为租户创建资源单元
unit1。CREATE RESOURCE UNIT unit1, MAX_CPU=5, MIN_CPU=5, MEMORY_SIZE= '32G', MAX_IOPS=10000, MIN_IOPS=5000, LOG_DISK_SIZE=5301023539200;为租户创建资源池
pool1,指定资源单元为unit1。CREATE RESOURCE POOL pool1 UNIT='unit1', UNIT_NUM = 1, ZONE_LIST = ('zone1','zone2','zone3');创建一个租户
tenant_c,指定其 Locality 为F@zone1,F@zone2,C@zone3。CREATE TENANT tenant_c LOCALITY = 'F@zone1,F@zone2,C@zone3', PRIMARY_ZONE='zone1;zone2,zone3', RESOURCE_POOL_LIST=('pool1') SET ob_tcp_invited_nodes = '%';本示例中,创建的租户默认为 MySQL 兼容模式租户,如果需要创建 Oracle 兼容模式租户,需要通过系统变量 ob_compatibility_mode 显式指定
ob_compatibility_mode='oracle'。
场景 B:为已有租户增加 C 副本
假设当前集群中有一个名为 tenant_c 的租户,其 Locality 为 F@zone1,F@zone2,F@zone3,租户的资源池为 pool1,其 ZONE_LIST 范围为 'zone1','zone2','zone3'。现在需要为租户增加 C 副本,可以增加 zone4,然后修改租户的 Locality 为 F@zone1,F@zone2,F@zone3,C@zone4,步骤如下:
在集群中添加新的 Zone zone4。添加 Zone 的详细操作,参见 添加 Zone。
向 zone4 内增加节点。添加节点的详细操作,参见 添加节点。
创建资源单元
unit2。CREATE RESOURCE UNIT unit2, MAX_CPU=5, MIN_CPU=5, MEMORY_SIZE= '32G', MAX_IOPS=10000, MIN_IOPS=5000, LOG_DISK_SIZE=5301023539200;创建资源池
pool2,指定资源单元为unit2。CREATE RESOURCE POOL pool2 UNIT = 'unit2', UNIT_NUM = 1, ZONE_LIST = ('zone4');为租户增加资源池
pool2。ALTER TENANT tenant_c RESOURCE_POOL_LIST = ('pool1','pool2');修改租户的 Locality 为
F@zone1,F@zone2,F@zone3,C@zone4。ALTER TENANT tenant_c LOCALITY = 'F@zone1,F@zone2,F@zone3,C@zone4';
使用列存副本
使用 C 副本的方式
V4.6.0 之前,需要配置独立的 ODP,业务请求通过独立的 ODP 发送到列存副本。
即配置单独一套 ODP,在它上面配弱读、路由和
init_sql(常见ob_route_policy = COLUMN_STORE_ONLY)设置请求路由策略。V4.6.0 及以上,C 副本不需要部署独立的 ODP,C 副本与 F 副本共用 ODP,由数据库自动选择路由策略,也就是 列存副本自动路由。
更多关于列存副本自动路由判定规则的详细信息,请参见AP 查询与列存副本路由判定规则。
V4.6.0 之前:部署独立 ODP,业务请求通过 ODP 发送到 C 副本
适用于 V4.6.0 之前,或 V4.6.0+ 仍需 专用独立 ODP 将 AP 弱读固定路由到 C 副本、与 TP 链路隔离的场景。
部署 ODP
在可与集群互通的机器上部署 专用于访问 C 副本 的 ODP(建议单机部署),版本 不低于 ODP V4.3.2。步骤见 部署 ODP。
配置路由转发策略及弱读
使用 root@proxysys 登录该 ODP,例如:
obclient -uroot@proxysys -h10.10.10.1 -P2883 -p
下列 组合一 与 组合二 任选其一。选择建议:
- 已明确 C 副本所在 Zone,且希望弱读流量按 Zone 收敛时,优先 组合一(
proxy_primary_zone_name)。 - 更希望按 副本类型(ColumnStore) 路由、而不绑定固定 Zone 名时,使用 组合二(
route_target_replica_type)。
说明
ODP 配置项含义可能与字面不完全一致。示例中 obproxy_read_consistency = 1 表示弱一致性读。obproxy_read_only 等参数请以当前使用的 ODP 版本文档为准。
组合一
只读与弱读相关项:
obclient> ALTER PROXYCONFIG SET obproxy_read_only = 0; obclient> ALTER PROXYCONFIG SET obproxy_read_consistency = 1;配置弱读情况下,ODP 所有请求仅路由到 C 副本所在的 Zone,同时生成 C 副本的查询计划。例如, C 副本所在的 Zone 为
zone4。obclient> ALTER PROXYCONFIG SET proxy_primary_zone_name='zone4'; obclient> ALTER PROXYCONFIG SET init_sql='set @@ob_route_policy = COLUMN_STORE_ONLY';
组合二
只读与弱读相关项:
obclient> ALTER PROXYCONFIG SET obproxy_read_only = 0; obclient> ALTER PROXYCONFIG SET obproxy_read_consistency = 1;配置弱读情况下,所有请求仅路由到 C 副本,同时生成 C 副本的查询计划:
obclient> ALTER PROXYCONFIG SET route_target_replica_type = 'ColumnStore'; obclient> ALTER PROXYCONFIG SET init_sql='set @@ob_route_policy = COLUMN_STORE_ONLY';配置弱读情况下,所有请求仅选择从副本,当从副本都不可用时,断开和客户端的连接:
obclient> ALTER PROXYCONFIG SET proxy_route_policy='TARGET_REPLICA_TYPE_FOLLOWER_ONLY';
修改成功后,通过以下语句,确认修改结果:
obclient> SHOW PROXYCONFIG ALL LIKE 'obproxy_read_only';
obclient> SHOW PROXYCONFIG ALL LIKE 'obproxy_read_consistency';
obclient> SHOW PROXYCONFIG ALL LIKE 'proxy_primary_zone_name';
obclient> SHOW PROXYCONFIG ALL LIKE 'init_sql';
obclient> SHOW PROXYCONFIG ALL LIKE 'route_target_replica_type';
obclient> SHOW PROXYCONFIG ALL LIKE 'proxy_route_policy';
配置成功后,OLAP 业务通过该 独立 ODP 接入,将查询定向到 C 副本。
V4.6.0 及以上:C 副本和 F 副本使用统一的 ODP,使用自动路由
适用于已完成 C 副本部署,且希望所有业务请求都通过统一的访问入口发送到数据库。请使用 与访问 F/R 相同的连接方式:经 同一套业务 ODP。
快速使用示例(表名、条件请按环境替换):
-- 1. 确认自动路由相关变量存在及默认值
SHOW VARIABLES LIKE 'ap_query%';
-- 2. 本会话保持默认 AUTO 或显式指定(可选)
SET SESSION ap_query_route_policy = 'AUTO';
-- 3. 查看是否出现列存侧相关计划(以实际算子为准)
EXPLAIN SELECT COUNT(*) FROM your_table;
是否在 C 副本上规划只读部分,由 ap_query_route_policy、ap_query_cost_threshold、ap_query_replica_fallback 与 路由判定规则、读一致性等共同决定。完整变量说明见 列存副本自动路由。
列存副本自动路由
从 OceanBase V4.6.0 起,可通过系统变量控制只读查询是否 尝试 在 C 副本 上执行。
其中,ap_query_route_policy 是 列存副本自动路由 的控制开关用于决定系统是否对符合条件的分析型查询尝试生成面向 C 副本 的执行计划。有关详细判定规则,参见 AP 查询与列存副本路由判定规则。
前置条件
- 租户:目标租户已在 Locality 中配置 C 副本,且副本可提供读服务。
- 变量:执行
SHOW VARIABLES LIKE 'ap_query%';,确认ap_query_route_policy、ap_query_cost_threshold、ap_query_replica_fallback等是否存在。
系统变量说明
下列变量用于列存副本自动选择;含义以集群 SHOW VARIABLES 及当前版本文档为准。
ap_query_route_policy 取值
| 取值 | 含义 |
|---|---|
| OFF | 关闭列存副本自动选择逻辑;相关查询按行存等默认路径规划(与 V4.6.0 之前行为一致)。 |
| AUTO | 默认值,由优化器按规则与代价 自动判断是否尝试 列存侧计划。 |
| FORCE | 在满足前提条件时,优先尝试 在 C 副本上执行只读查询。 |
obclient> SHOW VARIABLES LIKE 'ap_query_route_policy';
obclient> SET ap_query_route_policy = 'AUTO';
obclient> SET ap_query_route_policy = 'FORCE';
ap_query_cost_threshold:在 AUTO 下,单并行度 计划代价超过该阈值时,参与是否尝试列存侧计划的判断。默认值请以 SHOW VARIABLES 为准(常见默认 200000)。
obclient> SHOW VARIABLES LIKE 'ap_query_cost_threshold';
obclient> SET SESSION ap_query_cost_threshold = 300000;
ap_query_replica_fallback:目标为 C 副本但副本不可用或无法完成规划时,是否允许回退行存。
| 取值 | 含义 |
|---|---|
| ON | 允许回退,查询尽量成功。 |
| OFF | 不因该原因回退,可能报错。 |
obclient> SHOW VARIABLES LIKE 'ap_query_replica_fallback';
obclient> SET SESSION ap_query_replica_fallback = OFF;
与 ob_route_policy 的关系
ap_query_route_policy:作用于 优化器是否尝试生成列存侧计划(自动选择 / 强制 / 关闭)。ob_route_policy:作用于 OBServer 内部读路径可选的副本类型(如COLUMN_STORE_ONLY等)。
二者 层次不同,不是简单替代关系。经独立 ODP 访问 C 副本 时,常在 init_sql 里设置 ob_route_policy = COLUMN_STORE_ONLY,与 ODP 路由项共同把流量导向列存;列存副本自动路由 则以 OBServer 侧 ap_query_route_policy 变量为主。
按场景选择策略
| 场景诉求 | 策略建议 | 说明 |
|---|---|---|
| 智能选择:先试行存,满足 AP 特征再试 C 副本(多数场景) | ap_query_route_policy = AUTO(默认) |
结合代价、并行等判断;可用 ap_query_cost_threshold 调节。 |
| 会话内分析读尽量稳定走 C 副本 | ap_query_route_policy = FORCE |
写入仍走主副本。 |
| 与升级前列存行为对齐、关闭自动选列存 | ap_query_route_policy = OFF |
按行存等默认路径规划。 |
| C 副本故障时可接受回落行存 | ap_query_replica_fallback = ON(默认) |
降低查询失败率。 |
| 必须只走列存,失败则报错 | ap_query_replica_fallback = OFF |
|
| AUTO 下更多查询尝试列存 | 降低 ap_query_cost_threshold |
如 100000。 |
| AUTO 下仅很重查询才尝试列存 | 提高 ap_query_cost_threshold |
如 300000。 |
| 单条 SQL 与会话默认不同 | Hint /*+opt_param('ap_query_route_policy', '...')*/ |
见下文查询级别控制。 |
简要步骤
在了解上述系统变量的配置方法及不同场景下的策略选择后,您可以参考以下步骤完成设置。
ap_query_route_policy的默认值为AUTO。如有需要,您可以手动将其修改为FORCE或OFF。- 仅当租户中存在可用 C 副本,且查询满足相关判定规则时,系统才会尝试生成列存计划。
- 可以通过
ap_query_cost_threshold调节AUTO模式下对重查询的敏感度;通过ap_query_replica_fallback控制在 C 副本不可用或规划失败时是否回退到行存执行。
操作顺序建议:
- 确认已完成上文 部署列存副本 一节中的 C 副本部署。
- 核对变量:
SHOW VARIABLES LIKE 'ap_query%'; - 按需本会话调整,例如:
SET SESSION ap_query_route_policy = 'FORCE';或调整ap_query_cost_threshold、ap_query_replica_fallback。 - 对目标 SQL 做
EXPLAIN,查看是否出现列存相关算子;并结合DBA_OB_CS_REPLICA_STATS/CDB_OB_CS_REPLICA_STATS排查 C 副本状态。
查询级别控制
适用于 临时验证、单条 SQL 调优 或 不改会话全局默认 时,在语句上使用 Hint:
该语句尽量按列存侧策略规划(在策略与副本允许的前提下):
obclient> EXPLAIN SELECT /*+opt_param('ap_query_route_policy', 'FORCE')*/ * FROM t1, t2 WHERE t1.c1 = t2.c1;该语句关闭自动选列存:
obclient> EXPLAIN SELECT /*+opt_param('ap_query_route_policy', 'OFF')*/ * FROM t1, t2 WHERE t1.c1 = t2.c1;
列存副本上的读一致性
V4.6.0 之前,访问 C 副本时仅支持弱读(ob_read_consistency = 'weak')。V4.6.0 起支持在 C 副本上 强一致性读。变量全局说明见 ob_read_consistency。
列存副本强读
强读场景下,事务层会基于 全局一致性快照 检查 C 副本(Follower)日志回放是否已追到可读点;必要时 等待回放,再执行查询。以下为 便于理解的简化步骤,非实现细节承诺:
- 获取全局一致性快照版本(如经 GTS)。
- 判断 C 副本是否已回放到该版本。
- 未就绪则等待;就绪后执行读。
注意
强读可能因等待回放而增加延迟;极短的点查通常不适合在 C 副本上强读。
强读与弱读对比
| 特性 | 强读 | 弱读 |
|---|---|---|
| 一致性 | 与主副本一致 | 最终一致,可能略旧 |
| 延迟 | 可能需等待回放 | 通常更低 |
| 典型场景 | 高一致性 AP 读 | 可容忍短暂延迟的 AP 读 |
| 设置 | ob_read_consistency = 'strong'(默认) |
ob_read_consistency = 'weak' |
建议: 一致性要求高时使用强读(默认);可容忍延迟时,弱读往往性能更好。
在 ap_query_route_policy = AUTO 时,系统会综合 弱读、并行度、代价阈值 等条件判断是否尝试列存侧计划;弱读是可能触发尝试的条件之一,并非唯一条件。完整条件表见 AP 查询与列存副本路由判定规则。
验证与排错建议
建议按顺序排查:
- C 副本:租户 Locality 是否包含 C;副本是否可用;行转列是否完成(见 暂为行存 与
CDB_OB_CS_REPLICA_STATS/DBA_OB_CS_REPLICA_STATS)。 - 变量:
SHOW VARIABLES LIKE 'ap_query%';,确认ap_query_route_policy等是否符合预期。 - 执行计划:对目标 SQL 执行
EXPLAIN(或查看实际执行计划),是否出现列存侧相关算子。 - 仍未走列存:对照 AP 查询与列存副本路由判定规则 中的基本条件与 AUTO 触发项。
无 C 副本的租户:开启上述变量通常不会改变无列存时的基本规划行为。