OceanBase 物理备库（Physical Standby）的 Redo 日志应用机制，以下描述正确的是？

培训 & 考证
#1

A. 备库通过持续从主库拉取 Clog，并在备库侧完整回放 Clog 中的每个事务，回放过程中会对数据行加锁，因此备库无法提供只读查询服务。

B. 备库采用并行回放技术，可以同时应用多个日志流的 Redo 日志，并通过依赖关系管理保证事务提交顺序，从而缩短同步延迟。

C. 备库默认的回放模式是实时回放（Real-time Apply），即每收到一批 Redo 日志就立即回放，不等待日志缓冲积累。

D. 当备库回放遇到主库已提交但备库尚未应用的事务时，备库上的只读查询会阻塞等待该事务回放完成，以确保读一致性。

2 个赞
#2

解析 ：
OceanBase 备库为了降低同步延迟，采用了并行回放机制。每个租户的多个日志流（Log Stream）可以独立并行应用 Redo 日志。同时，系统内部通过日志流间的依赖关系跟踪（如分布式事务跨多个日志流），确保有依赖关系的事务按正确顺序回放，从而在保证数据一致性的前提下最大化回放并发度。

  • A 错误 ：备库回放使用的是行级多版本机制 ，不需要对数据行加锁，因此支持只读查询 。这是备库可读的基础。
  • B 正确 ：并行回放技术是 OceanBase 备库低延迟同步的关键设计。
  • C 错误 ：备库的 Redo 应用模式可以通过参数配置，存在实时回放 和定时回放 （如每隔 N 秒批量应用）两种模式，并非默认真实时。通常为了减少资源占用，会采用近似实时的批量应用。
  • D 错误 ：备库上的只读查询读取的是当前已回放完成的快照版本 ，不会阻塞等待未回放的事务。这通过 MVCC 实现，查询看到的是某个时间点的已提交数据版本。
1 个赞
#3

正确答案：B

1 个赞
#4

正确答案是：B，楼主请采纳我！！！！

答案解析：

  • A. 错误。
    • 原因：OceanBase 支持备库提供只读查询服务（即“弱一致性读”）。虽然备库在回放 Clog 时会对数据加锁，但它是基于 MVCC（多版本并发控制）机制运行的。读请求会读取已提交的历史快照版本，与正在回放的写事务互不阻塞，因此备库完全可以作为只读节点对外提供服务。
  • B. 正确。
    • 原因：这是 OceanBase V4 及以后版本的核心特性之一。为了降低主备同步延迟，OceanBase 引入了并行回放技术。备库会将不同日志流（Log Stream）或无依赖关系的事务进行并行回放，同时通过严格的依赖关系管理来保证事务提交的逻辑顺序，从而在保证一致性的前提下大幅缩短了同步延迟。
  • C. 错误。
    • 原因：OceanBase 备库的回放模式主要分为“实时回放”和“异步回放”。在实际生产中，为了提高回放效率并减少 IO 开销，通常采用的是批量回放（Batch Apply），而不是每收到一批就立即单条回放。此外，默认配置往往更倾向于兼顾性能与延迟的策略，而非绝对的逐条实时回放。
  • D. 错误。
    • 原因：OceanBase 备库提供的只读查询属于弱一致性读。如果备库上发起只读查询时，遇到主库已提交但备库尚未回放完成的事务，查询不会阻塞等待该事务回放完成，而是直接返回当前已经回放到的最新一致性时间点的数据。只有显式指定了强一致性读（如 READ_CONSISTENCY=STRONG）且系统支持的情况下，才可能涉及等待机制，但这并非默认行为。
1 个赞
#5

答案是B

#6

选择BC
B 正确
OB 物理备库采用多日志流并行回放架构：不同 Unit（日志流）的 Redo 可以多线程同时应用；内部依靠事务依赖图、TS 时序管控全局提交顺序，大幅降低主备同步延迟。
C 正确
备库默认回放模式为 Real-time Apply（实时回放）：日志拉取一批、解析一批、立刻回放一批，不会堆积大段日志缓冲区；另有批量回放模式可手动切换用于大追数场景。

其余选项错误
A 错误
备库回放 Clog 时不会加业务行锁，回放是底层物理数据修复，和业务 DML 锁机制隔离；
物理备库本身天然支持只读查询，并非无法提供读服务。
D 错误
备库只读查询不会阻塞等待未回放事务：查询会取当前已回放完成的最大安全快照 TS，读取已稳定的数据；通过单调读 / 有界旧读控制一致性，不会阻塞 SQL 等待回放追赶。