企业官网建设流程全解析

简介：OceanBase OBCA部分题目是一份面向认证备考者的精选练习文档，适合数据库管理员、运维人员及正在备考OBCA的开发者，尤其适合已系统学习过OceanBase基础、希望用题目检验掌握程度的阶段。内容以判断题、多选题和单选题形式组织，覆盖分库分表架构的局限、OceanBase分布式特性、Zone与租户资源池管理、分区副本分布、事务隔离级别、组件组成与OB Proxy角色等核心考点。文档共1个docx文件，压缩包大小仅26KB，轻量便携，适合碎片时间刷题和考前集中自测。目前已有2276人学习使用，题库虽为“部分”但典型性较强，可帮助考生快速定位薄弱环节。通过练习可加深对Paxos协议强一致性、RPO=0与RTO<30秒高可用指标、动态扩容缩容、MySQL/Oracle双模式兼容等知识点的理解；针对主副本Redo-Log同步、合并触发方式、会话变量作用域等易混判断题，文档也给出了清晰答案，配合描述中的解析，能有效提升应试信心。

1. 一份 OBCA 题库能拆出多少 OceanBase 硬知识

刚开始接触 OceanBase 的人，最容易把 OBCA 认证想成“背答案就能过”的考试。实际上你把这份题库过一遍就会发现，里面几乎没有死记硬背的送分题，全是围绕分布式数据库架构设计的判断和选择：Paxos 协议怎么保证强一致、Zone 和副本怎么分布、租户和资源池怎么扩缩容、参数在哪一级生效。这些知识点不是零散的，它们串起来就是 OceanBase 从部署到运维的完整链路。这份题库适合两类人：一类是准备考 OBCA 的从业者，考前刷题能快速定位薄弱点；另一类是正在选型或刚接手 OceanBase 的 DBA 和架构师，通过判断正误来校准自己对分布式数据库的认知，顺便把易混淆的运维命令和参数边界搞清楚。本文按考点模块拆解这套题，把答案背后的原理、易错点、命令用法一起讲透。

2. Zone、副本与 Paxos：集群高可用的三个核心考点

2.1 Zone 到底是什么：从“打 tag”到容灾级别

题库里反复出现 Zone 的概念，判断“Zone 是逻辑概念，是给集群内的一批机器打上同一个 tag”为正确。这里要理解 Zone 不是物理机房，而是一组 OBServer 的逻辑分组。部署时你可以让一个 Zone 对应一个城市，也可以让一个 Zone 对应一个机房甚至一个机架，这就决定了容灾的粒度。常见误解是把 Zone 等同于“可用区”，实际上 OceanBase 的 Zone 是可配置的，同一批机器打上不同 tag 就可以划分成不同 Zone。

容灾能力取决于 Zone 的物理分布方式。题库里那道“企业在一个城市有 2 个机房，将 2 个 Zone 部署到 1 个机房中，将另一个 Zone 部署到另一个机房中，是否提供机房级容灾”的判断是错的。原因很直接：Paxos 协议组要求多数派副本存活才能继续服务，三副本中两个副本在同一机房，这个机房一旦整体宕机，多数派就丢了，服务不可用。要真正做到机房级容灾，三个 Zone 必须分散在至少两个机房，最好是三个机房各一个。

2.2 副本数与 Paxos 的关系：不是机器多副本就多

单选“一个 3 Zone、每 Zone 5 台 OBServer 的集群，一个分区有几份副本”答案是 3。很多人看到 15 台机器就想选更多，但副本数是由 Zone 数决定的：每个分区在每个 Zone 中默认只有一份全能型副本，Paxos 协议组以分区为单位组建，参与投票的副本分布在各个 Zone 中。同理，5 个 Zone 的集群，一个分区最多有 5 份全功能型副本，因为每个 Zone 最多放一份。

这里要区分“副本数”和“资源单元数”两个概念。资源单元计算题是这样的：3 个 Zone、每 Zone 5 台 OBServer，租户资源池的 UNIT_NUM=3，问多少台服务器上有该租户的资源单元，答案是 9。UNIT_NUM 表示每个 Zone 中分布的资源单元个数，总数为 Zone 数乘以 UNIT_NUM。如果 UNIT_NUM=4，结果就是 12。这类题的本质是理解 Unit 是资源调度的最小单位，它决定租户在物理服务器上的资源分布，而不是副本数。

2.3 Paxos 与 Redo-Log：多数派落盘就够，不必等全部

题库判断“主副本需要收到所有从副本落盘成功的消息后才能响应应用”为错误，这是理解 Paxos 的关键。标准的主备同步通常要等备机确认才返回，OceanBase 的 Paxos 协议只需要多数派（例如三副本中的两副本）确认 Redo-Log 落盘即可响应。少数副本不可用时，仍能实现 RPO=0、RTO<30 秒，靠的就是这个机制——多数派里有最新日志，选主后不丢数据。

这个设计连带影响另一个考点：脑裂问题。Paxos 通过多数派投票机制保证任何时候只有一个主副本被选举出来，即使网络分区发生，少数派也无法选出新主。题库里判断“OceanBase 的 Paxos 可以彻底规避脑裂问题”为正确，原因就在这里。传统主备方案在双选时容易出现两个主，Paxos 从协议层面就避免了多数派冲突的可能。

提示：Paxos 组成员以分区为粒度，而不是以表或租户为粒度。所以一个分区的主副本在哪个 Zone、哪个 OBServer 上，是由分区级别的选举决定的，不同分区的主副本可以分布在不同机器上，这也为负载均衡提供了空间。

2.4 主副本分布与负载均衡：不能聚焦，只能打散

判断“主副本只能打散到所有 Zone 内，不能聚焦到一个 Zone”为正确，这个限制的原因在于读写性能和容灾均衡。如果所有主副本都聚焦在一个 Zone，读写流量集中在这一个 Zone 的机器上，其他 Zone 的机器只能提供备份服务，算力和带宽都被浪费。OceanBase 的 RootService 会根据负载情况动态调整主副本位置，尽量让每个 Zone 的主副本数量均衡。扩容新机器加入集群后，集群也会基于负载均衡策略把部分主、从副本迁移到新机器上，实现整体均衡。

这里有一个容易混淆的点：主副本打散到 Zone 是“尽量均衡”，但假如某个 Zone 的机器规格特别高，是否可以让它承担更多主副本？题库明确判断“不能聚焦”，说明这是架构原则，不是单纯性能优化的选择。运维时不要试图用参数把主副本集中到某个 Zone，那相当于主动放弃分布式的扩展能力。

3. 租户、资源池与系统参数：运维命令题的答题套路

3.1 租户与资源池的关系：创建后不是不能改

题库判断“租户的资源池一旦创建完成，就不可改变”为错误，对应的是 OceanBase 支持动态扩容缩容的能力。租户在逻辑上类似传统数据库实例，但底层资源由资源池决定。资源池关联资源单元定义（比如 2C8G、4C16G）和 UNIT_NUM（每个 Zone 分布的单元数）。扩容有两种路径：一是修改资源池中的 UNIT_NUM，增加单元个数；二是修改资源单元规格，把 2C8G 调整为 4C16G。集群资源不足时，先添加 OBServer 节点完成集群扩容，再通过增加资源单元的个数完成租户扩容。

还有一个判断题：“一个租户在同一个 Server 上可以有一个或多个资源单元 UNIT”为正确。这里的场景是跨 Zone 部署时，同一个 OBServer 上可能承载同一租户在多个 Zone 的多个 Unit？严格讲同一租户在同一 OBServer 上通常只有一个 Unit 分布，但题目考察的是资源单元的调度灵活性，答案是正确。实际运维中你不需要手动管理 Unit 的物理位置，RootService 会自动调度。

3.2 系统参数与变量：两套体系，别混用

参数分为集群级和租户级两个级别，这是多选原题。集群级参数作用于所有 OBServer，租户级参数只作用于特定租户。如果同时存在集群级和租户级参数，集群级覆盖租户级。这句话看起来矛盾——既然租户级参数更精细，为什么反被覆盖？注意覆盖的含义是“当两个级别的同名参数同时存在时，查询生效值以集群级为准”，OceanBase 的设计是集群级参数作为默认值，租户级参数作为租户内的自定义值，但租户级参数的取值范围不能超出集群级定义的边界。

查询参数的属性用SHOW PARAMETERS LIKE '%pattern%'，修改参数用ALTER SYSTEM SET name=value。系统变量则用SHOW VARIABLES和SET命令管理，分会话级和全局级。判断题“会话变量只对当前会话生效”为正确，而“Global 级变量修改后对当前已打开的 session 也生效”为错误——全局变量只对新建立的会话生效，已打开的会话保持原有值。这是很多 DBA 的直觉盲区，刚执行完SET GLOBAL发现当前连接的值没变，以为是命令没生效，其实是作用范围的问题。

3.3 ALTER SYSTEM 的边界条件：不带条件会报错

多选原题“关于 ALTER SYSTEM SET XX='YY'，以下说法正确的是”给出的答案是：如果不带任何条件会返回错误；可以修改某个 Zone 上的值；可以修改某台具体 OBServer 上的值；不能不带条件直接改所有 OBServer。很多人在 MySQL 里习惯了SET GLOBAL直接改全局变量，在 OceanBase 里对参数同样操作会翻车。OceanBase 要求每次修改参数时指定生效范围，要么用ZONE='z1'，要么用SERVER='ip:port'，要么显式声明作用级别。

ALTER SYSTEM命令同时还可以指定 Zone 或 OBServer，但最多同时指定 1 个。这个限制问的是“同时指定几个”，答案是 1。也就是说你可以一条命令只针对一个 Zone 或一台 OBServer 修改参数，但不能一条命令同时限定多个 Zone。需要修改多个 Zone 时，要么写多条命令，要么用更大的范围级别（如集群级）。

注意：查询参数属性用SHOW PARAMETERS，而查询变量用SHOW VARIABLES。参数是系统级配置，变量是会话/租户级可动态调整的值，两套命令对应两套体系。考试时出现“通过哪个命令查询参数的属性”这类题，看到 Parameters 关键词就不要选 Variables 相关选项。

3.4 创建租户与资源池的实操命令

OCP 图形化界面里创建租户很方便，但黑屏命令行也要能看明白。管理员通过CREATE RESOURCE POOL命令创建资源池，创建资源单元时指定 CPU、MEMORY 即可，但 OPS、DISK_SIZE、SESSION_NUM 为可选参数。判断题“创建资源单元仅指定 CPU、MEMORY 参数即可，无需指定 OPS、DISK_SIZE、SESSION_NUM”为正确，说明这些参数有默认值，不会因为没指定就报错。

连接租户的用户名格式是“用户名@租户名”，例如root@sys。连接到 Oracle 租户时，黑屏工具要用 OceanBase 客户端，而不是标准 MySQL 客户端；JDBC 连接 Oracle 租户要用 OceanBase 自己的 JDBC 驱动，不能用 MySQL 标准驱动或 Oracle 标准驱动。这一点很多人都踩过坑——刚开始连 Oracle 租户时经验主义地用了 MySQL 的驱动，结果报协议错误。

4. 避坑手册：这份题库里最容易错的地方

4.1 误以为所有从副本落盘才返回：强一致不等于慢

现象：做判断题“主副本需要收到所有从副本落盘成功的消息后才能响应应用”时选了正确，理由是基于传统主备库的经验。

原因：OceanBase 的 Paxos 协议只需要多数派确认，不需要全部确认。三副本中两个副本落盘成功即可返回成功，剩余一个副本异步追赶。这不是折中方案，而是 Paxos 的数学保证——多数派中一定包含最新日志。

解决：记住公式“强一致 = 多数派落盘”，不是“全部落盘”。题目如果出现“所有”“全部”这类绝对化字眼，通常就是判断题的陷阱。

4.2 用 SHOW VARIABLES 查参数：两条命令的适用范围搞反

现象：单选“通过哪个命令可以查询参数的属性”时，在SHOW PARAMETERS和SHOW VARIABLES之间犹豫，最后选了后者。

原因：很多从 MySQL 转过来的 DBA 习惯用SHOW VARIABLES看配置，但 OceanBase 里 parameters 和 variables 是两套独立体系。Parameters 是集群/租户级配置项，Variables 是会话级变量。

解决：看到“参数属性”四个字，直接锁定SHOW PARAMETERS LIKE '%pattern%'。看到“变量”，才考虑SHOW VARIABLES。我把这条写进了自己的速记表：Param 是静态配置，Variable 是动态状态。

4.3 把 OBProxy 当成有状态服务：它不做计算也不持久化

现象：多选“以下对 OBProxy 的描述正确的是”，漏选了“OBProxy 是一个无状态的服务进程，不做数据持久化”。

原因：OBProxy 位于应用和 OBServer 之间，看起来像个网关，容易让人误以为它参与事务处理和计算。

解决：OBProxy 只做路由，把 SQL 请求转发到合适的分区主副本所在 OBServer。它本身不存储数据、不参与事务执行、不做数据持久化。是否部署在独立服务器上是部署策略问题，不是架构要求。理解这一点，就能记住为什么 OBProxy 可以水平扩展多个实例，不会成为单点。

4.4 计算副本数时被机器数带偏：结果只跟 Zone 数相关

现象：3 Zone、每 Zone 5 台 OBServer，判断“一个分区有几份副本”，选了 15 或 6。

原因：把 OBServer 数量等同于副本数量，或者把 UnitNum 的逻辑混进副本计算。

解决：分区副本数的计算只看 Zone 数。每个 Zone 内有多台 OBServer，但一个分区的一个副本只落在该 Zone 的某一台 OBServer 上。所以 3 个 Zone = 3 份副本，5 个 Zone = 5 份全功能副本。至于哪台机器承载副本，那是 RootService 的调度问题。

4.5 备份介质漏选阿里云 OSS：本地存储思维残留

现象：多选“OceanBase 备份恢复支持哪些存储介质”，选了 NFS、IP-SAN、FC-SAN，漏掉了阿里云 OSS。

原因：习惯性把备份介质想成本地磁盘或传统存储网络，忽略了 OceanBase 在公有云上的部署形态。

解决：OS 是公有云对象存储，OceanBase 支持将备份直接写入 OSS。这个选项在考察你是否了解 OceanBase 在阿里云公有云和专有云中的存储适配。本地机房用 NFS 或 SAN 没毛病，云上环境优先考虑 OSS。

5. 验证与提速：把题库过成场景化速查表的三个习惯

备考 OBCA 时，我习惯不按题目顺序刷，而是先按知识点类别给题库打标签，再为每个标签建立一条“场景记忆”。这套方法也同样适用于日常排障：遇到错误现象时回查对应标签的题目，往往能快速定位根因。

第一步，把数字类考点集中记忆。这份题库里的关键数字是：峰值 6100 万次/秒、单表 3200 亿行、RPO=0、RTO<30 秒、时钟偏差 100 毫秒、压缩 2 次、major_freeze 每日凌晨触发。我一般做成一张卡片贴在工位旁，每次做实验前扫一眼，记忆力比背书持久。尤其时钟偏差 100ms 这个数值容易漏，因为部署文档里写的是“RPC 允许的时钟偏差最大 100 毫秒”，超出这个范围会导致选举和日志同步异常。

第二步，按“判断题反向推导法”验证理解。每道判断题不要只看答案，而是把错题改成正确的语句读一遍，再看改完的语义是否严谨。比如“主副本只能打散到所有 Zone 内，不能聚焦到一个 Zone”是正确，如果把它改成“可以聚焦”就是错误，这时反问自己：为什么聚焦不行？答案是读写流量和容灾均衡。把每个错题都当成一次追问，比背三十道原题更有效。

第三步，用命令行做实验验证参数效果。题库里提到ALTER SYSTEM SET major_freeze_duty_time='02:00'表示每日凌晨两点自动发起一次内存冻结。我在测试环境实际执行了这条命令，再用SHOW PARAMETERS LIKE '%major_freeze%'查确认生效，这时才对参数级别有了直观感受——必须指定 Zone 或 Server 作用域，否则命令直接报错。建议你也搭一套单机版 OceanBase 或直接用 OBD 部署一个最小三节点环境，把题目中涉及的命令全部跑一遍，跑不通的地方回头看题库里的判断题，思路瞬间就通了。

这套刷题方法的核心是把题库当成“错题索引”而不是“答案宝典”。每错一道题，就把它对应的架构原理写一遍，写不出来的地方再回看文档和实验输出。我在备考期间形成的习惯是：每次做实验之前强制走一遍参数查询、副本数推断和 Redo-Log 落盘逻辑，做完实验再回看一遍错题集，直到看到题目能直接说出它考的是哪个架构特性。希望这个方法对你的 OBCA 备考和 OceanBase 日常运维都有实际帮助。

本文还有配套的精品资源，点击获取