简介OceanBase OBCA部分题目是一份面向认证备考者的精选练习文档适合数据库管理员、运维人员及正在备考OBCA的开发者尤其适合已系统学习过OceanBase基础、希望用题目检验掌握程度的阶段。内容以判断题、多选题和单选题形式组织覆盖分库分表架构的局限、OceanBase分布式特性、Zone与租户资源池管理、分区副本分布、事务隔离级别、组件组成与OB Proxy角色等核心考点。文档共1个docx文件压缩包大小仅26KB轻量便携适合碎片时间刷题和考前集中自测。目前已有2276人学习使用题库虽为“部分”但典型性较强可帮助考生快速定位薄弱环节。通过练习可加深对Paxos协议强一致性、RPO0与RTO30秒高可用指标、动态扩容缩容、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_NUM3问多少台服务器上有该租户的资源单元答案是 9。UNIT_NUM 表示每个 Zone 中分布的资源单元个数总数为 Zone 数乘以 UNIT_NUM。如果 UNIT_NUM4结果就是 12。这类题的本质是理解 Unit 是资源调度的最小单位它决定租户在物理服务器上的资源分布而不是副本数。2.3 Paxos 与 Redo-Log多数派落盘就够不必等全部题库判断“主副本需要收到所有从副本落盘成功的消息后才能响应应用”为错误这是理解 Paxos 的关键。标准的主备同步通常要等备机确认才返回OceanBase 的 Paxos 协议只需要多数派例如三副本中的两副本确认 Redo-Log 落盘即可响应。少数副本不可用时仍能实现 RPO0、RTO30 秒靠的就是这个机制——多数派里有最新日志选主后不丢数据。这个设计连带影响另一个考点脑裂问题。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 namevalue。系统变量则用SHOW VARIABLES和SET命令管理分会话级和全局级。判断题“会话变量只对当前会话生效”为正确而“Global 级变量修改后对当前已打开的 session 也生效”为错误——全局变量只对新建立的会话生效已打开的会话保持原有值。这是很多 DBA 的直觉盲区刚执行完SET GLOBAL发现当前连接的值没变以为是命令没生效其实是作用范围的问题。3.3 ALTER SYSTEM 的边界条件不带条件会报错多选原题“关于 ALTER SYSTEM SET XXYY以下说法正确的是”给出的答案是如果不带任何条件会返回错误可以修改某个 Zone 上的值可以修改某台具体 OBServer 上的值不能不带条件直接改所有 OBServer。很多人在 MySQL 里习惯了SET GLOBAL直接改全局变量在 OceanBase 里对参数同样操作会翻车。OceanBase 要求每次修改参数时指定生效范围要么用ZONEz1要么用SERVERip: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”为正确说明这些参数有默认值不会因为没指定就报错。连接租户的用户名格式是“用户名租户名”例如rootsys。连接到 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 亿行、RPO0、RTO30 秒、时钟偏差 100 毫秒、压缩 2 次、major_freeze 每日凌晨触发。我一般做成一张卡片贴在工位旁每次做实验前扫一眼记忆力比背书持久。尤其时钟偏差 100ms 这个数值容易漏因为部署文档里写的是“RPC 允许的时钟偏差最大 100 毫秒”超出这个范围会导致选举和日志同步异常。第二步按“判断题反向推导法”验证理解。每道判断题不要只看答案而是把错题改成正确的语句读一遍再看改完的语义是否严谨。比如“主副本只能打散到所有 Zone 内不能聚焦到一个 Zone”是正确如果把它改成“可以聚焦”就是错误这时反问自己为什么聚焦不行答案是读写流量和容灾均衡。把每个错题都当成一次追问比背三十道原题更有效。第三步用命令行做实验验证参数效果。题库里提到ALTER SYSTEM SET major_freeze_duty_time02:00表示每日凌晨两点自动发起一次内存冻结。我在测试环境实际执行了这条命令再用SHOW PARAMETERS LIKE %major_freeze%查确认生效这时才对参数级别有了直观感受——必须指定 Zone 或 Server 作用域否则命令直接报错。建议你也搭一套单机版 OceanBase 或直接用 OBD 部署一个最小三节点环境把题目中涉及的命令全部跑一遍跑不通的地方回头看题库里的判断题思路瞬间就通了。这套刷题方法的核心是把题库当成“错题索引”而不是“答案宝典”。每错一道题就把它对应的架构原理写一遍写不出来的地方再回看文档和实验输出。我在备考期间形成的习惯是每次做实验之前强制走一遍参数查询、副本数推断和 Redo-Log 落盘逻辑做完实验再回看一遍错题集直到看到题目能直接说出它考的是哪个架构特性。希望这个方法对你的 OBCA 备考和 OceanBase 日常运维都有实际帮助。本文还有配套的精品资源点击获取