OceanBase v4.4.2_CE_BP2: Distributed CDC, RPO=0 Sync, and Auth Plugin Updates

by

Overview

OceanBase released version 4.4.2_CE_BP2 on July 16, 2026. This build focuses on enhancing high availability through formal RPO=0 strong synchronization, migrating OBCDC to a distributed service architecture, and expanding MySQL compatibility with new authentication and utility functions.

High Availability and Synchronization

The release formalizes support for strong synchronization (RPO=0) in primary-standby scenarios. Two protection modes are now available:

  • Maximum Protection Mode: Ensures no data loss if the primary fails. Transactions only commit after REDO logs are persisted on both the primary and the strong sync standby. If the standby is unavailable, write services on the primary are halted.
  • Maximum Availability Mode: Prioritizes cluster availability while maintaining high data protection. If the primary-standby link lags beyond NET_TIMEOUT (default 30s), the system automatically degrades strong sync to asynchronous to restore primary service. It reverts to strong sync once the lag falls below HEALTH_CHECK_TIME (default 60s).

Additionally, a new delayed replication feature allows standby databases to apply logs with a configurable delay (using ALTER SYSTEM SET LOG_RESTORE_SOURCE = '...DELAY=N'). This is useful for creating a safety window against accidental DDL/DML operations.

OBCDC Evolution: Distributed Architecture

A major architectural shift is the transition of OBCDC from a single-machine dynamic library (libobcdc.so) to a distributed service cluster. This addresses bottlenecks in CPU, memory, and I/O that previously limited scalability.

The new architecture consists of several independent roles:

  • Coordinator: Manages cluster tasks and fault recovery.
  • LogFetchService: Fetches CLOG per LogStream (LS) and caches it locally.
  • CDCWorker: Assembles, sorts, and parses REDO logs.
  • MsgStorager & MsgService: Persist messages to object storage and merge/format for client delivery.

This update also optimizes the handling of UPDATE statements. Previously, logical updates causing row migration were split into DELETE and INSERT events. This version merges these back into a single UPDATE event for downstream consumers when the primary key/partition key has not actually changed, preserving the original SQL semantics.

MySQL Compatibility and Authentication

MySQL compatibility is enhanced with two key additions:

  • to_single_byte() Function: A new function to convert full-width characters to half-width, aiding in data cleaning and migration.
  • caching_sha2_password Plugin: Support for MySQL 8.0's strong SHA-256 authentication plugin is added. However, the default authentication plugin remains mysql_native_password. Users must explicitly set default_authentication_plugin or run ALTER USER ... IDENTIFIED WITH caching_sha2_password to use the new plugin.

Performance and Observability

Performance improvements include:

  • Optimized hard parse memory usage for complex SQL.
  • Enhanced JSON expression performance (JSON_EXTRACT, JSON_VALUE).
  • Batch parallel execution for ALTER TABLE ... COMMENT and CREATE INDEX.
  • Reduced network overhead for global index operations.

Observability is improved with new views like [G]V$OB_LS_LOG_TRANSPORT_STAT and [G]V$OB_LS_LOG_REPLAY_STAT, which provide per-LogStream granularity for monitoring replication lag and replay progress.

Breaking Changes and Migration Notes

Several changes require attention during migration:

  • PL PS Protocol Overload: A breaking change affects stored procedures/anonymous blocks with multiple overloads when using the PS protocol. Previously, the server might silently pick the wrong overload. Now, it throws PLS-00307: too many declarations match this call. The recommended fix is to upgrade the OceanBase JDBC driver (ob-jdbc) to 2.4.16+ and enable obIncludeOutOrNullParamTypeInfo=true in the connection string.
  • Tenant Cloning: Primary tenant cloning is disabled. Only standby tenants can be cloned, and this feature is marked as experimental.
  • HDFS Export: The 5GB single-file limit for SELECT INTO OUTFILE to HDFS has been removed.

Upgrade Paths

Upgrading to v4.4.2_CE_BP2 requires specific intermediate versions depending on your current state:

  • Direct Upgrade: V4.4.2_CE, V4.4.2_CE_BP1, V4.4.0_CE, V4.4.0_CE_BP1, V4.4.1_CE.
  • Two-Step Upgrade: V4.3.5_CE (via BP6) or V4.2.5_CE (via BP7) must first be upgraded to the target version.