OceanBase “Three‑Site Five‑Center” Architecture for City‑Level Automatic Disaster Recovery

Traditional “Two‑Site Three‑Center” Solution

In the conventional approach, two cities host three data centers each, forming independent database clusters with synchronous intra‑city replication and asynchronous inter‑city replication, providing strong consistency and read‑write separation.

Problems of this model include:

DDL operations must be executed separately on read and write databases.

Replication software has poor fault tolerance, requiring manual intervention.

Performance bottlenecks cause significant data lag between primary and standby.

Complex initial configuration and high consistency‑check costs.

Limited adaptability; after a primary‑site failure, standby sources must be reconfigured.

“Three‑Site Five‑Center” Solution

OceanBase’s “three‑site five‑center” design solves city‑level disaster recovery and read‑scale challenges at the database layer. Compared with the traditional scheme, it offers:

No data loss during a single‑city outage.

Read performance remains unchanged; write latency increases modestly with city distance.

Automatic primary failover and autonomous read‑replica synchronization without manual steps.

Transparent to upper‑layer applications—no code changes required.

Eliminates reliance on third‑party replication tools, using only the database’s built‑in multi‑replica mechanism.

The deployment consists of five read/write zones (R/W Zone1‑5) and four read‑only zones (RO Zone6‑9) distributed across three cities, each city hosting two data centers. Write traffic is directed to the read/write zones of two cities, while reads are served locally from the nearest read‑only or read/write replica, ensuring high availability and low latency.

Read‑Only Zone Mechanism

To support the “three‑site five‑center” architecture, OceanBase introduces read‑only zones where partition replicas are read‑only and participate only in log replication, not in Paxos voting. This expands cluster read capacity without affecting write latency, allowing linear scaling of read throughput and reducing deployment costs.

Conclusion

Thanks to these advantages, the OceanBase “three‑site five‑center” deployment with read‑only zones will be progressively adopted for high‑availability, high‑performance financial core services, establishing a new norm for database cluster architecture in the financial sector.