OceanBase
  • 产品
  • 解决方案
  • 客户
  • 合作伙伴
  • 资源与服务
  • 文档
  • 社区
云控制台登录 / 注册
  • 免费试用
OceanBase AI 数据平台

基于湖库一体架构,统一管理结构化、半结构化与非结构化等多模态数据,一个系统承载事务处理、实时分析与 AI 工作负载。

一体化能力

TP 事务处理

关键业务稳定运行,保障数据零丢失

AP 实时分析

事务分析一体,驱动智能决策与运营

AI 现代负载

统一多模态数据,支撑生产级应用

关键产品
OceanBase 分布式数据库

首批通过安全可靠测评,面向关键业务

OceanBase 集中式数据库

集中式架构,兼具性能与成本优势

OceanBase AI 湖库

湖库一体的多模态数据处理平台

OceanBase DataPilot

企业级 AI 数据分析 Agent

OB Cloud

一体化云数据库,提供多云一致体验

OceanBase 数据库一体机

软硬一体,极致性能与高可靠性保障

OceanBase AI 一体机

开箱即用的 AI 数据库一体机

OMA 迁移评估工具

全链路数据库迁移评估

OMS 数据迁移工具

一站式数据传输与同步

OCP 运维管理工具

数据库全生命周期管理

ODC 开发者工具

数据库开发与管控协同

OAS 自治服务工具

数据库智能诊断与自治

通用场景
全场景业务系统 OLTP
实时分析混合负载
异地多活
多基础设施部署
一站式传统数据库升级
混合云部署
一库多芯软硬件混合部署
分布式数据库单机部署
大存储类数据库降本
冷数据归档降本
多实例资源整合
分库分表一体化升级
高并发场景
数据中台
行业解决方案
国有大行和股份制银行核心系统解决方案
区域性银行核心系统解决方案
寿险核心系统解决方案
产险核心系统解决方案
资管交易类系统解决方案
资管 TA 清算类系统解决方案
运营商核心系统解决方案
人社核心系统解决方案
电力核心系统解决方案
行业专区
银行专区

助力银行完成各类核心业务系统升级

保险专区

寿险、产险核心系统升级的更佳选择

零售专区

助力200+零售行业客户规模化落地

DB 大咖说
oceanbase爱奇艺

百亿级卡券业务的“单库双擎”架构升级

oceanbase四川银行

800个测试用例选定分布式数据库

oceanbase太平洋保险

先难后易,核心系统数据库升级复盘

行业案例
oceanbase交通银行

核心数据库的“分布式革命”

oceanbase中国移动

B域核心CRM&BOSS近乎零改造分布式升级

oceanbase理想

打造领先的智能制造系统和自动驾驶体验

演讲实录
oceanbase中国联通

集团应用分布式数据库覆盖B/O/M域

oceanbase国泰海通

智能推送系统稳定支撑单日亿级消息处理量

oceanbase中国联合航空

中国首款机票盲盒背后的数据库力量

用户实践
oceanbase北京银行

最快速度完成40余套系统国产数据库升级

oceanbaseVIVO

替换 MySQL 分库分表,探索成本效益最优

oceanbase滴滴

数据库大规模运维体系建设及落地实践

合作伙伴
合作伙伴类型
联合解决方案
产业生态伙伴
经销商伙伴
技术服务伙伴
培训认证伙伴
生态联合解决方案
神州信息 x OceanBase 银行核心系统
长亮科技 x OceanBase 新核心系统
中电金信 x OceanBase 金融分布式核心系统
天阳科技 x OceanBase 贷记卡方案
易诚互动 x OceanBase 手机银行方案
恒生 x OceanBase UF3.0/O45/TA/估值方案
商业发行版
云树®数据库软件 ActionDB
服务
支持与服务
提交工单
软件下载
OceanBase 企业版
OceanBase 社区版
OB Cloud
学习
培训与认证
在线课堂
在线体验
开发者
开发者中心
资料
行业报告与白皮书
官方博客
年度发布会资料
开发者大会资料
oceanbase白皮书

金融核心系统数据库升级路径与场景实践

oceanbase白皮书

人社关键业务数据库一体化升级实践

产品文档
oceanbaseOceanBase 数据库
数据库一体机
oceanbaseOceanBase AI 数据库
工具与组件
oceanbaseOB Cloud 云数据库
驱动和中间件
快速上手
OceanBase 数据库
OB Cloud 云数据库
知识库
汇聚常见产品使用问题案例
在线体验

Demo与实验,感受 OceanBase 的核心能力与应用场景

OceanBase 最佳实践
了解 OceanBase 分布式数据库的架构与系统原理
技术博客

技术解析 | 用户实践 | 社区月报

在线课堂

电子书 |视频课程|在线培训

Developer Hub
应用开发Demo | 数据开发与集成工具
问答论坛

快速答疑 | 常见问题 | 技术交流

社区活动

Meetup | 技术公开课

GitHub

查看源码 | 贡献代码 | 建议反馈

加入社区

社区组织 | 社区用户贡献 |开发者贡献

进入社区首页
oceanbase数据库大赛

第六届OceanBase数据库大赛

oceanbase免费课程

《Easy Data x AI》:面向所有 AI 爱好者的 Data 与 AI 基础知识入门教程

切换语言
  • 中文站 - 简体中文
  • International - English
  • 日本站 - 日本語

OceanBase

OceanBase 海扬数据库始创于 2010 年,是完全自主研发的数据库公司。2020年开始独立商业化运作,历经15年大规模核心场景验证,目前是中国数据库的领军企业之一。从分布式数据库到 AI 数据库,为企业提供安全、稳定、可扩展的数据底座,推动数据基础设施全面拥抱 AI 时代。

关于我们

关于 OceanBase最新动态资质荣誉客户专家委员会招贤纳士合作伙伴年度发布会开发者大会

资源与服务

支持与服务文档知识库软件与工具下载培训与认证在线体验数据库专题视频

社区

快速上手开发者中心博客活动学习问答GitHub

数据库百科

分布式数据库国产数据库OLTP 数据库OLAP 数据库HTAP 数据库数据库向量数据库向量检索

联系我们

服务热线:
400-109-0633
商务咨询
培训认证技术支持媒体合作
京公网安备11010802047223号京公网安备11010802047223号
京ICP备20024574号-1
合字B1.B2-20250395
网站服务协议隐私协议安全响应协议
OceanBase 版权所有 © 2026 基础资源和备案服务由阿里云提供
文档反馈
  1. 文档中心
  2. OceanBase 数据库
  3. 分布式版
  4. V4.6.0
  5. OceanBase AP
  6. 部署 OceanBase AP
  7. 部署与使用列存副本
分布式版-V4.6.0
  • What's New
  • 简介
  • 快速上手
  • 应用开发
  • 部署
  • 升级
  • 数据迁移
  • 管理数据库
  • AP
    • AP 版本更新记录
    • AP 概述
    • AP 核心特性
    • 快速体验 OceanBase AP
    • 部署 OceanBase AP
      • AP 部署概述
      • 典型 AP 架构部署指南
      • AP 场景下的参数配置推荐
      • 部署与使用列存副本
      • AP 查询路由判定规则
    • 数据表设计
    • 数据传输
    • 数据加工
    • 数据湖
    • 查询加速
    • 导出数据
    • 数据可视化
    • 性能诊断和调优
    • 生态集成
    • 实践教程
    • AP FAQ
  • AI
  • 生态集成
  • 实践教程
  • 参考指南
  • 常见问题
  • 版本发布记录
  • 术语
  1. 文档中心
  2. OceanBase 数据库
  3. 分布式版
  4. V4.6.0
  5. OceanBase AP
  6. 部署 OceanBase AP
  7. 部署与使用列存副本

部署与使用列存副本

更新时间:2026-06-17 13:19:58

github-fill编辑
编组分享

为支持 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 副本的租户,步骤如下:

  1. 找到一台能够与当前集群网络互通的机器,并在该机器上部署 ODP。

    为防止资源争抢,建议 ODP 单独部署在一台机器上。部署 ODP 时,要求其版本必须为 ODP V4.3.2 及以上版本。有关部署 ODP 的详细操作,参见 部署 ODP。

  2. 为租户创建资源单元 unit1。

    CREATE RESOURCE UNIT unit1,
        MAX_CPU=5,
        MIN_CPU=5,
        MEMORY_SIZE= '32G',
        MAX_IOPS=10000,
        MIN_IOPS=5000,
        LOG_DISK_SIZE=5301023539200;
    
  3. 为租户创建资源池 pool1,指定资源单元为 unit1。

    CREATE RESOURCE POOL pool1
        UNIT='unit1',
        UNIT_NUM = 1,
        ZONE_LIST = ('zone1','zone2','zone3');
    
  4. 创建一个租户 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,步骤如下:

  1. 在集群中添加新的 Zone zone4。添加 Zone 的详细操作,参见 添加 Zone。

  2. 向 zone4 内增加节点。添加节点的详细操作,参见 添加节点。

  3. 创建资源单元 unit2。

    CREATE RESOURCE UNIT unit2,
        MAX_CPU=5,
        MIN_CPU=5,
        MEMORY_SIZE= '32G',
        MAX_IOPS=10000,
        MIN_IOPS=5000,
        LOG_DISK_SIZE=5301023539200;
    
  4. 创建资源池 pool2,指定资源单元为 unit2。

    CREATE RESOURCE POOL pool2
        UNIT = 'unit2',
        UNIT_NUM = 1,
        ZONE_LIST = ('zone4');
    
  5. 为租户增加资源池 pool2。

    ALTER TENANT tenant_c RESOURCE_POOL_LIST = ('pool1','pool2');
    
  6. 修改租户的 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 副本不可用或规划失败时是否回退到行存执行。

操作顺序建议:

  1. 确认已完成上文 部署列存副本 一节中的 C 副本部署。
  2. 核对变量:SHOW VARIABLES LIKE 'ap_query%';
  3. 按需本会话调整,例如:SET SESSION ap_query_route_policy = 'FORCE'; 或调整 ap_query_cost_threshold、ap_query_replica_fallback。
  4. 对目标 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)日志回放是否已追到可读点;必要时 等待回放,再执行查询。以下为 便于理解的简化步骤,非实现细节承诺:

  1. 获取全局一致性快照版本(如经 GTS)。
  2. 判断 C 副本是否已回放到该版本。
  3. 未就绪则等待;就绪后执行读。

注意

强读可能因等待回放而增加延迟;极短的点查通常不适合在 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 副本的租户:开启上述变量通常不会改变无列存时的基本规划行为。

相关文档

  • 列存副本
  • AP 查询与列存副本路由判定规则
  • 典型 AP 架构部署指南
  • 列存 FAQ

本文目录

使用限制与注意事项部署列存副本场景 A:新建包含 C 副本的租户场景 B:为已有租户增加 C 副本使用列存副本使用 C 副本的方式V4.6.0 之前:部署独立 ODP,业务请求通过 ODP 发送到 C 副本V4.6.0 及以上:C 副本和 F 副本使用统一的 ODP,使用自动路由相关文档
有帮助
无帮助
反馈
AI